fix(app): reduce catalog retention and status animation work - #45406

Summary

• Unwrap complete provider/model snapshots before conversion so each consumer does not subscribe to every nested catalog field.
• Share converted catalogs through weak keys for both input arrays. Whole-list replacements still invalidate the result, and old snapshots are not kept alive by the cache.
• Reduce the session progress APNG from 90 to 30 fps while keeping the same poses, interpolation, 1.2-second loop, recoloring, and reduced-motion fallback.
• Add a production-renderer memory workload, reactive catalog tests, and an APNG asset test. Fix same-origin API mocking so production HTML/assets reach Vite instead of receiving mock API 404s.

Measurements

Windows, based on v2 at 954cdc7bc8. These are scoped measurements, not a claim that total desktop RAM has been halved.

Retained renderer heap

Production app bundle in Chromium, 1,200-model fixture, ten alternating session switches. Three fresh-context runs per variant. Each sample uses explicit GC followed by Runtime.getHeapUsage; this does not measure normal allocation peaks, worker heaps, Electron main/GPU memory, or server RAM.

Raw usedSize bytes for the three runs:

{
  "initial": {
    "before": [39324920, 39363668, 39326380],
    "after": [14258828, 14252852, 14248204]
  },
  "afterTenSwitches": {
    "before": [51407084, 51301364, 51267936],
    "after": [24918964, 24752676, 24933860]
  }
}

The workload also verifies that a location-scoped catalog.updated event refreshes the displayed model name after navigation.

Reproduce from packages/app:

bunx playwright test --config e2e/performance/playwright.config.ts timeline/provider-memory-benchmark.spec.ts --repeat-each=3

Status indicator CPU

The actual production component was bundled with Vite and rendered as two visible 16px indicators in an isolated Electron 42.3.3 / Chromium 148 window, with hardware acceleration enabled. Five-second warm-up, three 30-second samples per variant. CPU is the sum of cumulative CPU-time deltas across Browser, GPU, Tab and Utility processes, divided by wall time and 20 logical CPUs, then multiplied by 100.

Mean reduction: 31.0%. The runs were sequential, not interleaved A/B trials. One candidate sample exceeded 1%, so neither a consistent sub-1% ceiling nor application-wide CPU savings is established. No meaningful RAM improvement was measured for the indicator alone.

Navigation Guardrail

The existing cold/hot tab benchmark passed with the review pane open and closed, three runs per case for each catalog variant. No wrong-destination, blank, unknown, or replaced review-host samples were observed. Timing results were mixed; this PR makes no navigation-latency improvement claim. Median settled observations (before -> after, milliseconds): closed/cold 190.3 -> 172.6; closed/hot 133.0 -> 88.0; open/cold 137.6 -> 177.1; open/hot 161.9 -> 157.2. More samples are needed to distinguish the open/cold increase from run variance.

Validation

• packages/app: bun run test:unit (540 passed), bun run test:browser (47 passed).
• packages/app: bun typecheck, bun run typecheck:e2e.
• packages/session-ui: bun typecheck, focused APNG test (passed).
• Production memory workload: three before and three after runs; additional catalog-refresh verification passed.
• Production navigation workload: three runs per cold/hot and open/closed case, each variant.
• Production streaming workload at native CPU speed: 160/160 deltas delivered, no row/Markdown remount, no blank samples or bottom drift.
• Isolated Electron reduced-motion check: grid hidden, center dot visible and static; grid restored when reduced motion is disabled. Still screenshots do not prove animation smoothness.
• Independent code review found no concrete correctness issues.

Remaining Target

The starting goal was a 50% reduction in total desktop RAM and CPU below 1%. This PR reaches the halfway mark for the measured catalog-heavy renderer heap only. Full packaged-app RSS/private-working-set improvement, sustained streaming CPU, and server memory still need a matched end-to-end measurement. The live app and its server were not restarted or replaced. Private live heap snapshots remain local and are not included in this PR.