buildWatermark() calls Array.join() on a lines array whose size is
derived from tile dimensions divided by wmFontSize. For files with very
many lines the codeFontSize (and thus wmFontSize) approaches zero,
making charsPerLine and lineCount astronomically large and blowing past
JS's string length limit.
Fix by:
1. Clamping wmFontSize to a minimum of 1.0 to handle pathologically
large files.
2. Capping charsPerLine at 400 and lineCount at 150 — the watermark is
purely decorative so this cap has no visible impact.
- Server now returns metadata-only tree on initial load (no file content
in the JSON payload); content is served on-demand via the new
GET /api/repos/{key}/file?path=... endpoint
- Cache still stores full content; strip_content() runs in-memory before
the response is sent
- Frontend fetches file content lazily in _fetchContent() when a tile
enters the LOD view, preventing a massive upfront JSON download for
large repos (e.g. claude code)
- computeColorRanges() is now deferred to first _showCode() call instead
of running synchronously for every file during load()
- Cap label fontSize at 5 world units to prevent giant text on large tiles
- troika-three-text MSDF rendering for resolution-independent code text
- highlight.js syntax highlighting with Catppuccin Mocha colors
- Lazy text pool: max 25 concurrent code meshes, created on demand
- LOD throttled to every 3 frames, OSD every 10
- 45° tiled watermark (repo/path/filename) behind code
- OSD: breadcrumb, file stats, zoom level
- Search: / or Ctrl+F to find and fly to files
- Keybindings: WASD pan, Q/E rotate, Z/C zoom, Space overview, ? help modal
- Mouse wheel zoom vs trackpad pan detection via event frequency
- Zip GBK filename encoding fallback for Chinese filenames
- Docker volume persistence for SQLite cache
