[mike-doctorina]

Fixes DoctorinaAI/doctorina#4770 — Loaded 5 of 4 resources on web startup.

The bug

The numerator and the denominator came from two different sets of resources.
resourcesCount counts the pre-cached set (Core + Required), while
bootstrap.js added every resource key the SW reported a terminal status
for — including Optional files served lazily by the fetch handler, which is
unbounded. So the overflow is systematic, and its size is whatever the startup
happens to touch (the field report saw both 5 of 4 and 6 of 4).

Reproduced on the example app at 0.1.5, cold load:

counted 9 resources against a total of 6

The rendered text stopped at 6 of 6 only because the overlay is disposed on
first frame — the fonts land a moment later. In production, where the app takes
longer to boot, the overflow is on screen.

The fix

sw-progress messages now carry two fields:

• counted — whether this resource is one of the resourcesCount ones.
  The SW still reports everything it serves (useful for display); only counted
  resources may enter a numerator rendered against that total.
• swVersion — which worker spoke. During an update load an old controller
  and a new installing worker both post to the same client, with different
  manifests and different totals; the bootstrap now ignores anyone but its own
  build, so the denominator cannot change mid-load. A mismatch is logged once,
  so a bootstrap.js and an sw.js from different builds can't freeze the
  counter silently.

Everything goes through a single createProgressReporter, and precacheResources
now takes its category list (COUNTED_CATEGORIES) from the same module, so "what
is pre-cached" and "what is counted" cannot drift apart again. The rendered number
is also clamped — unreachable given the above, but it is what the user reads.

App-shell bugs found on the way

• index.html was ignore, so it never reached the manifest and the fetch
  handler's manifest['index.html'] lookups were permanently empty. The shell was
  neither pre-cached nor reported as progress, and on a cold profile an offline
  navigation had nothing to fall back to. Now required, stored under one
  canonical index.html cache key shared by precache and navigation.
• SPA deep links were dropped. The manifest lookup ran before the
  request.mode === 'navigate' branch and returned early for any route without an
  entry of its own — making that branch unreachable for exactly the routes that
  need it.
• reloadIfForeignController resolved sw.js against location.href rather
  than the document base URL register() uses. On /chat/42 it expected
  /chat/sw.js, judged the real /sw.js controller foreign, unregistered it and
  reloaded the page — once per tab session, on every deep link. Caught by the new
  deep-route e2e test.

Second pass: what the first cut of the shell fix broke

Making the navigate branch unconditional handed every same-origin navigation to
the shell handler, and the shell handler wrote whatever it got.

• Any same-origin page could replace the app shell. A page the host serves
  outside the SPA rewrite answers a navigation with its own HTML, and storing
  that under index.html leaves the app unable to boot from cache at all.
  Firebase Hosting excludes /__/auth/** from the rewrite, and Firebase Auth
  puts its handler and its iframe there whenever authDomain is the app's own
  domain — which is the case in production. Reproduced in Chromium against the
  example app: after one navigation to offline.html, /deep/route renders the
  offline page.

  Only a request for the shell refreshes the shell now (/, /index.html);
  deep links read that cache and never write it. Paths under a host-reserved
  prefix (RESERVED_PATH_PREFIXES = ['__/']) are passed straight to the network,
  so a sign-in document no longer goes through fetchWithRetry — which
  downgrades a navigation request's mode — nor falls back to the app shell.
  A redirected response is never stored: browsers refuse to replay one for a
  navigation.

• A failed cache write discarded a good page. cache.put sat inside the same
  try as the fetch, so quota pressure — routine for a wasm-sized app — turned a
  200 from the origin into the stale cached copy, or into the literal
  503 Offline page on a profile with nothing cached yet, while the network was
  fine. Cache reads and writes are each contained now, and nothing after a
  successful fetch can reject the promise handed to respondWith. In the same
  spirit cacheFirst degrades to a plain fetch when CacheStorage is unusable,
  and progress.report is best-effort — telemetry for an overlay should not be
  able to fail a navigation or a main.dart.wasm.

• The manifest described an index.html the origin never serves. cleanup
  substitutes {{sw_version}} after the manifest is hashed. Harmless while the
  shell was ignore; not once it became a manifest entry. Verified on a real
  build: manifest 0674fe…/1069 vs on-disk 637e02…/1067. The substitution now
  runs before hashing and the entry is refreshed; the version stays derived from
  the pre-substitution manifest, so it is unchanged and still deterministic.

Known limitation

A warm load has no install event, so the counter does not reach its total:
measured cold 7 of 7, warm 2 of 7 on the example. The shell is answered
during the navigation itself, before any page script exists to hear the message;
a JS-build entry point is never requested on a wasm-capable browser; the rest can
come from the browser's HTTP cache without a fetch event. The overflow this PR
fixes is gone, but the count is a floor, not a completion signal — documented as
such in docs/service-worker.md. Closing that gap needs a protocol addition (the
SW replying with the counted resources already in the content cache) and is left
for a follow-up rather than folded into a release whose job is not to break
startup.

Verification

Against the example app (flutter build web --release --wasm → sw:generate):

• 0.1.5 cold load: 9 counted resources against a total of 6.
• 0.1.6 cold load: Loaded 1 of 7 … Loaded 7 of 7, monotonic, reaching the total
  exactly when the last pre-cached resource settles. Warm load and five consecutive
  cold loads: no overflow.

Suites: 247 Vitest, 98 Dart (unit + integration), 16 Playwright — all green.

New tests:

• e2e/progress-counter.spec.ts — cold / warm / five-consecutive-cold, asserting on
  the SW messages rather than the overlay text (which stops updating once the app
  takes over).
• e2e/app-shell.spec.ts — the shell is pre-cached, answers an offline navigation,
  and answers a route the origin 404s.
• e2e/app-shell-integrity.spec.ts — visiting a same-origin page outside the SPA
  leaves the cached shell intact, and a deep link still gets the app afterwards.
  Both fail against the first cut of the shell fix.
• src/sw/__tests__/progress.test.ts, plus pipeline cases for foreign versions,
  uncounted resources and a fixed denominator.
• src/sw/__tests__/fetch-handler.navigation.test.ts — host-reserved navigations
  are passed through; the shell is refreshed only from a request for the shell;
  a redirected response is not stored; a page the origin served is still returned
  when the cache write fails; precache and the fetch handler agree on the shell
  cache key.

Also fixed a pre-existing red test: bails out safely when sessionStorage throws
spied on Storage.prototype.setItem, which jsdom does not route sessionStorage
through, so the spy never fired.

Breaking-ish

resourcesSize now describes the counted set rather than every cacheable resource,
so it agrees with resourcesCount. Anything reading it as "total bytes on disk"
should sum the manifest instead. Nothing in the Doctorina app consumes sw-progress.

Release

Needs a 0.1.6 tag to publish; DoctorinaAI/doctorina pins sw ^0.1.6 in
DoctorinaAI/doctorina#4770's branch and cannot go green until then.