TrailView ground plan, step 7: the device cache of built cells and the route prebuild #3200

Part of #3096, plan after the 2026-11-07 review, step 7. Size: M.
Depends on: steps 1b (#3193) and 2 (#3195), so that a cell is one stable product. This is the phone's path to the load target, not an option.

Problem

• The owner does not accept a bake of records, faces or bins. So every client builds its cells.
• A warm load is not faster than a cold one: the worker CPU is the cost, not the network. The town cells about the eye alone cost several seconds of WASM per load.
• A phone has two fast cores, and Safari's WASM speed is not measured yet.
• After steps 1 and 2, a cold jump into a town lands at about 1.5–3 s on desktop, more on a phone (an estimate). While riding, cells build ahead, so a cold jump does not matter there. A planned route tells the viewer which cells come.

Design

1. The device cache. The viewer keeps each built cell (the records block, the mesh bytes, the cell's stamp items of step 1b) in Cache Storage, keyed by the release, the crate hash and the hash of the rule tables. Before it builds a cell, the plan worker reads the cache; after a build, it writes the cell. A size cap evicts the least recently used cells. The iOS app later keeps the same entries in its own store.
2. The route prebuild. When a route is planned, the plan worker builds the cells along it, within the mesh range on each side, in the background at the lowest priority, into the cache. It yields to every near-first job of step 2. Estimate: 100 km is about 700 cells, under a minute of phone CPU, about 70 MB.

Invariants

1. A cell from the cache is byte-equal to a cell that the client builds (the crate is a pure function; the key holds every input that changes bytes).
2. An entry with another key is never read. A corrupt or partial entry is dropped and rebuilt.
3. The cache is never on the critical path: a miss costs no more than today.
4. The prebuild never delays a near-first job, and never changes the frame time.

Done when

• A test: for the fixture cells, a cached cell equals a built cell; a changed crate or rules hash misses.
• Time to a clean frame, cold and warm, at v17 and m1: develop | ground-plan | this branch. Target for warm: fetch plus corners, about 1 s.
• The prebuild of one 100 km route on desktop: cells, CPU time, bytes in the cache. Phone numbers only after plan-timing.html ran on the owner's iPhone (TrailView ground plan: measurements before the far-cell work (coarse records, stamp GPU time, iPhone, city caps) #3201).
• The frame time with GP0's method (walk and drive), with a prebuild running.
• Renders of the owner's views, develop | new: equal to ground-plan, from the cache and built.
• npx vitest run src/lib/trailview, npm run check.

Risks

• Storage quota and eviction in iOS Safari. Measure the quota on the owner's iPhone.
• A key that misses an input gives stale cells. The hashes come from the build, not from hand-kept versions.
• 70 MB per 100 km is device storage; the cap and the route's length decide.

Order

Last step. Steps 1b and 2 first, because they change what a cell holds and how the worker orders jobs.