Add rewrite planning docs for compatibility and modular architecture

[Copilot]

This PR adds rewrite-oriented documentation for the next VIKUS Viewer iteration. It introduces a compatibility checklist for the migration and a companion architecture document that outlines how to make the new viewer modular and reusable.

• New rewrite checklist

  • Adds 06-Rewrite-Checklist.md
  • Captures the compatibility surface that should remain stable during the rewrite:
    • legacy config contract
    • CSV/data expectations
    • asset loading behavior
    • layout behavior
    • filter/search behavior
    • hash/deep-link state
    • detail/info panel behavior
  • Calls out legacy values that should continue to be accepted, including titel and alfabetical-reverse

• New modularity strategy

  • Adds 07-Modularity-and-Reusability.md
  • Defines a target architecture for a more reusable viewer with clear boundaries between:
    • data loading and normalization
    • domain/layout/filter logic
    • app state and routing
    • rendering
    • UI
  • Describes reusable contracts for layouts, filters, render state, and compatibility handling
  • Proposes a phased migration path so modularization can happen without losing legacy behavior

• Documentation set alignment

  • Keeps both docs in the existing numbered, root-level documentation series
  • Positions the new material as follow-on guidance to the architecture and config reference docs already in the repo

Example excerpt from the compatibility checklist:

## 1. Lock compatibility scope

- [ ] Treat existing `config.json` files as the primary compatibility target
- [ ] Preserve current URL/hash-driven behavior before improving internals
- [ ] Keep legacy field names and values that existing projects depend on:
  - [ ] timeline field `titel`
  - [ ] `sortKeywords: "alfabetical-reverse"`