[Performance] Add responsive thumbnails and avoid eager full-catalog image decoding

[rwang23]

[Performance] Add responsive thumbnails and avoid eager full-catalog image decoding

Draft status: ready to create; not submitted by the audit run.
Priority: P1
Findings: ACT-019, ACT-020, ACT-021

Summary

The project correctly preserves full-resolution real-app captures as evidence, but those same 1440×810 PNGs are also used as routine Gallery card media. Theme Manager builds image nodes for the catalog and rebuilds cards on common state changes.

中文摘要：136 张实机证据图总计约 128.4 MiB，不应直接承担 Gallery 列表图和桌面端主题列表图。需要专门缩略图层、响应式加载、稳定 DOM 和明确详情入口。

Audit evidence

• The current 136 Full Skin capture PNGs total approximately 128.4 MiB.
• Gallery visualFor prefers the real capture. Cards use lazy loading after the first entries, but scrolling still requests 1440×810 evidence PNGs.
• All 68 card nodes are created in one pass.
• Theme Manager renderThemeList() creates cards and <img> elements again, and several mode/filter/search paths call it.
• Desktop images do not use browser lazy/decode hints even though prepared thumbnails exist.
• Gallery detail discovery relies heavily on a small arrow or double-clicking the visual; fixed-language accessible labels and stale fallback counts also remain.

Proposed direction

1. Preserve original PNGs as audit evidence, but generate 320/480/960 presentation variants (WebP/AVIF or measured fallback) with hashes and byte counts.
2. Extend Registry capture metadata with evidence and presentation variants without weakening existing evidence binding.
3. Use srcset, fixed dimensions, loading=lazy, and decoding=async in Gallery.
4. Keep a keyed/stable card DOM in Theme Manager; update visible attributes rather than recreating all image nodes.
5. Add virtualization or pagination only when measured catalog size requires it.
6. Make a clear single-click/keyboard “View details” action and fully localize accessible names/error states.

Acceptance criteria

• Gallery cards do not request the original 1440×810 evidence PNG during ordinary catalog browsing.
• Original evidence remains available on explicit demand with its version/hash/byte/readback metadata.
• Presentation variants are reproducible, integrity-addressed, and generated once for CI/desktop/site reuse.
• Initial Gallery transfer and per-card image budgets are measured and enforced in CI.
• Theme Manager decodes only visible/near-visible thumbnails during initial browse.
• Search/filter changes reuse stable image/card nodes where possible; mode changes update only affected visible sources.
• A card has a visible, keyboard-reachable details action that works on touch without double-click.
• All card/dialog accessible names and fallback/error states are localized.
• Tests cover missing variants, evidence fallback, 404s, mode switching, node reuse, and catalog growth.

Related audit findings

ACT-019, ACT-020, ACT-021.

A presentation-loading reference is available in demo/ui/thumbnail-loading.js, with a PR plan in demo/pr-blueprints/PR-07-thumbnail-and-rendering-performance.md in the audit bundle.

[rwang23]

Implemented in #26 and re-verified on current main (e2ed6e8). npm run check now validates 408 integrity-addressed responsive presentations, per-card and initial-media budgets, evidence-on-demand metadata, and stable keyed Theme Manager cards; the prior isolated Gallery browser QA covered the corresponding browsing and details flows.

The implementation uses a measured PNG presentation fallback within the enforced budget. Moving to WebP/AVIF later would be an optimization, not an unmet acceptance condition. Closing as completed.