[futurepaul]

Closes #775.

Flake: billing-page: after Checkout's return, Settings said "Your seat could not be read." for the lane's whole 30 s wait (run 41144092617, shard 4/4). Two checks failed, and #750 was held.

Cause (product, cell/shell/settings.js): settings read the seat once per visit (.catch(() => null)). A read that failed on its way left "could not be read" up until the person left settings and came back. Nothing read it again, so the lane's wait couldn't recover, and neither could a person. Still unknown, as the issue says: why that browser read failed while every GET /api/seat in the node logs answered 200. A request that never reached the node fits. #743's front door removes one such loss in dev, but a phone's network can lose one too.

Fix: a read is retried the way #765 retries the shell's: on its own and calmly.

• A read that failed on its way (no answer reached the page, or a 502, 503 or 504) is read again on its own: 3 s, doubling to 30 s, for up to 8 minutes from the first failure.
• Until every one answers, settings say what could not be read, as before. Then settings draw again once, the way an action's reload draws them.
• A failure that would come again (a 4xx, a 500) is shown as it is and not retried.
• Each visit's reads are its own. A retry whose visit is gone (the person left settings, or a newer load began) does nothing.

Test: shell-ui adds "a seat read that fails on its way…". The page's first GET /api/seat fails in the browser (TypeError: Failed to fetch, what a lost request gives). The check waits for "Your seat could not be read.", then for settings to read it again and show the seat, with no reload. The waits are on those conditions, the section's limit is unchanged, and billing-page's check is unchanged.

Proof: cargo xtask e2e --only shell-ui: 317 passed, 1 failed. The new check passed. The one failure was Apps' "closing and reopening Apps with access and card reads held", which is a test race of its own and doesn't touch settings' reads: its probe counts another app's card reads, so it can release before the new visit has read. That fix is a separate PR.

🤖 Generated with Claude Code

[alexlwn123]

Pass at 87ee3f8f9e7838edf240bdf3171ef9c951fffee4.

The change recovers Settings after a transient read failure while retaining load-generation and page guards. The small, local retry helper and focused browser regression fit #775; I found no blocking regression.

Validation: pinned Node syntax check passed; a disposable harness exercising the extracted retry helper passed recovery, permanent/transient status classification, exponential backoff and cap, elapsed-budget stopping, and closed/stale-load guards. CI check is green; all four e2e shards are still running. I did not run the full browser suite locally. The external engineering-style document named in AGENTS.md was unavailable at its specified path.