chore: sync the frontend template from 4dc033c to 8157ad4

The product was materialized from the template at `4dc033c` and has stayed
on it through 43 template commits, so it was missing all three rounds of
adapter remediation — including files it never had, such as the shared
`abortable-operation` primitive and the `exact-snapshot` decoder that
later fixes are written against. Taking only the newest round was not
possible for that reason: the delta is coherent only as a whole.

The product had not touched `src/adapters` at all since materialization,
so the 140-file delta applied with a three-way merge and no conflicts.
`package.json` was the single overlap and merged cleanly: the product owns
`name`, the template contributed `check:adapter-inventory`,
`check:remediation-ledger` and the image-resolve-signal type fixture.
All 24 product-owned files — README, index.html, CI workflow, i18n
catalog, home page, generated schemas, evidence scripts, component and
visual snapshots — are byte-identical to `main`.

`template.lock.json` now pins the synced revision and tree.

Verified in this repository, not inherited from the template: six type
projects, lint, nine gates (adapter inventory, remediation ledger,
registries, diagnostics, realtime boundaries, architecture, browser
file/storage boundaries, optional recipes, documentation), the production
build, and 2,054 of 2,073 tests. The 19 failures are all in
`tests/unit/ci-artifact-contract.test.ts` and are the same pre-existing
sandbox RLIMIT, EMFILE, umask and `/tmp` permission behaviour the template
records; four suites that failed once under parallel load pass in
isolation.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/operations/client-cache-and-storage-recovery.md

@@ -12,6 +12,26 @@ session/account Query lifecycle, strict query policy와 Web Storage v2 lifecycle
 현재 `DESIGNED_NOT_IMPLEMENTED`다. 아래 목표 절차를 현재 runtime의 보장으로
 해석하지 않는다.
 
+
+## Public cache staging repair와 offline activation (STO-03 ~ STO-05)
+
+- release marker는 "staging이 끝났다"는 **주장**이고 모든 entry의 존재·digest
+  증거가 아니다. 같은 manifest로 `stageRelease`를 다시 호출하면 runtime이
+  candidate를 재검증하고, browser eviction이나 부분 손상이 발견되면 그 owned
+  candidate만 삭제한 뒤 network에서 다시 stage한다. marker만 보고 성공을
+  반환하지 않는다.
+- 검증 중 abort나 읽기 불가(UNKNOWN)는 stage 성공이 아니며 active pointer를
+  건드리지 않는다. candidate를 임의로 삭제하지도 않는다.
+- `activateRelease`와 `cleanupOwned`는 network I/O가 없다. fetcher 없이도
+  동작하므로 offline rollback과 quota recovery cleanup이 `UNSUPPORTED`로 막히지
+  않는다. 두 operation은 Cache Storage와 mutation lock만 요구하고 실패 시
+  recovery는 `RETRY`다. `stageRelease`만 fetcher를 요구하며 recovery는
+  `ONLINE_ONLY`다.
+- variant를 사용하는 policy(`allowedVaryHeaderNames` 비어 있지 않음)는 반드시
+  `allowedResponseHeaderNames`에 `vary`를 포함해야 한다. 아니면 composition이
+  `TypeError`로 즉시 실패한다. 저장된 variant가 같은 key로 충돌하는 상태를 만들지
+  않기 위한 cross-field invariant다.
+
 ## 1. 변경할 수 없는 복구 원칙
 
 - 서버가 server state와 authorization의 source of truth다.