fix(clients): persist project icons across reloads and reconnects

[StiensWout]

Project icons fall back to generic icons while remote environments reconnect or the page reloads. Keep the last resolved URL during reconnects, and persist the icon image so cached sidebar entries can show their icons before the next remote response arrives.

The shared cache is scoped to the environment, workspace, and selected favicon path. Icons are fetched and stored exactly as served when they fit 32 KiB, which covers SVG, ICO, and small PNG favicons; only larger bitmaps are downscaled to 96×96 (48×48 retry) through createImageBitmap on web and expo-image on mobile, and larger SVGs stay remote. Downloads are capped at 4 MiB while streaming. Each icon is its own record: IndexedDB on web and desktop, a project-favicon row in client_cache on mobile so Settings → Client storage counts and clears it. The cache holds at most 128 entries and 1 MiB. Hydrate before restoring the cached sidebar; refresh when the image revision changes, retain the previous image during failures, and remove it on a confirmed missing-icon response or when its environment is removed. Signed URL and origin changes reuse the same saved image. Storage is best effort. No new native dependencies.

Validation: 69 focused tests plus web, mobile, and client-runtime typechecks. In an isolated browser with /api/assets/** aborted across reload, icons restore from storage for both a PNG project and a viewBox-only favicon.svg project, and stay visible after networking is disabled. Native mobile UI was not exercised.

Before: reloading with remote icon requests held, using sample thread titles.

After: the same requests remain held; the sidebar and breadcrumb use saved icons.

Recording of reload with remote icon requests held

After disabling networking and closing the WebSocket:

An SVG favicon without width/height attributes, which browsers report at a 300×150 natural size, was thumbnailed at half size by the earlier canvas approach. Storing the bytes as served fixes it (breadcrumb after reload with asset requests aborted):

Model: GPT-6. Harness: Codex in T3 Code. Follow-up fixes: Claude Fable 5, Claude Code in T3 Code.

Note

Persist project favicons across reloads and reconnects via shared cache and atom family

• Adds a shared projectFaviconCache in client-runtime that downloads, validates, and downscales favicon images into self-contained data URLs, then persists them platform-side so icons survive signed-URL rotation and reconnects.
• Web stores favicons in a dedicated IndexedDB database (projectFaviconCache.ts); mobile stores them in MobileDatabase under a new project-favicon cache kind (projectFaviconCache.ts).
• A new projectFaviconUrlAtom atom family replaces the old asset-URL hooks in both ProjectFavicon components, retaining the last successful image during connection failures and returning cached data when available.
• Both platforms hydrate the favicon cache on shell-cache load and clear it on environment clear; oversized raster images are downscaled (WebP on web, JPEG/PNG on mobile) before storage, bounded to 32 KiB per entry, 128 entries, and 1 MiB total.
• Risk: MobileDatabase gains a new list-cache operation and project-favicon ClientCacheKind; any out-of-tree consumers of the mobile database schema or operation vocabulary must add support for these values.

^{Macroscope summarized dd57844.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR introduces substantial web and mobile runtime behavior for persistent favicon fetching, image processing, storage, hydration, refresh, and clearing across connection lifecycles. Its cross-cutting production impact and new persistence layers warrant human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[cursor]

Bugbot is paused — on-demand spend limit reached

Bugbot uses usage-based billing for this team and has hit its on-demand spend limit.

A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue.

Dismissing prior approval to re-evaluate 1933a14

Dismissing prior approval to re-evaluate 176ee22

[juliusmarminge]

Pushed 8090a47 on top of 176ee22 to address the audit findings:

• SVG icons without width/height were thumbnailed at half size (Chrome and Firefox ≥ 141 report a 300×150 natural size for a viewBox-only SVG; Firefox 120–140 report 0×0, which produced a 1×1 WebP). The canvas result then persisted and replaced the correctly rendering live icon. Icons are now fetched and stored as served when they fit the 32 KiB limit; only larger bitmaps go through a downscaler (createImageBitmap on web, expo-image on mobile), and larger SVGs stay remote. favicon.svg is the first candidate the server checks, so this affected a large share of projects.

  

• Mobile persistence was untested and silently no-ops for SVG on iOS: writeToCacheAsync(imageRef) re-encodes with the ref's sd_imageFormat, which the SVG coder tags as SVG and cannot encode, so nothing is written. With bytes inlined directly, the native decoder is now only used for large bitmaps, where both platforms encode PNG/JPEG.

• One record per icon instead of a single JSON blob, so tabs no longer overwrite each other's entries (the Macroscope cross-tab finding). Web bumps the IndexedDB to v2 and drops the old store.

• Mobile rows live in client_cache under kind project-favicon, so Settings → Client storage counts and clears them; clearing also drops the in-memory images.

• Remote mobile icons key the expo-image disk cache by revision again, so signed-token rotation reuses cached bytes while a changed icon starts from the loading state (the Macroscope stale-loaded finding).

Verified in an isolated dev environment with a viewBox-only favicon.svg project and /api/assets/** aborted across reload. Focused tests (78) and typechecks for client-runtime, web, and mobile pass. Native mobile UI still not exercised.

Model: Claude Fable 5. Harness: Claude Code in T3 Code.

[cursor]

Bugbot is paused — on-demand spend limit reached

Bugbot uses usage-based billing for this team and has hit its on-demand spend limit.

A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue.