[flip-engineer]

Opening a large library built every recording card and every history row, while each two-second poll rebuilt and downloaded the complete catalog. On a 1,717-recording library this meant a 3.4 MB state response, 57,390 DOM nodes, and a 2.4-second main-thread stall under 6x CPU throttling.

Start cards/history with 24 entries, append recording batches as the user scrolls, and keep explicit expansion buttons. Search, sorting, tags, favorites, and archive still cover the whole catalog. Defer hidden cards, preserve card DOM on unchanged/job-only polls, and paint viewport covers across idle turns. Add database-triggered catalog revisions, cached snapshots, conditional catalog responses, bounded genre caching, and negotiated JSON gzip. Older API clients still receive complete snapshots. Prepare version 0.6.28.

Validation:

• Backend suite: 287 tests passed, 5 environment-dependent skips; additional genre-cache isolation test passed.
• 1,200-recording mobile regression covers full-catalog operations, incremental browsing/history, actual playback, and DOM preservation.
• All browser scenarios passed across the initial run and the corrected interceptor/remainder run, including mobile library loading, delayed state, score replay, acoustics, writer, studio refresh, desktop controls and real 4K/60 export.
• Packaged archive passed isolated installation, HTTP startup, fallback and persistent-workspace checks.
• Same throttled browser: explicit rendering 704 ms → 16 ms; largest observed task 2,432 ms → 279 ms. On a database backup: unchanged snapshot 1,976 ms → 0.989 ms; JSON catalog 3,380,798 → 707,564 bytes with gzip. Catalog contents matched exactly.

The first cold catalog snapshot still takes about two seconds on this library, and its payload remains proportional to collection size. This change does not implement server-side pagination or claim measured performance on the user's physical phone.