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/browser-file-storage-recovery.md

@@ -13,6 +13,24 @@ probe는 현재 `DESIGNED_NOT_IMPLEMENTED`다. 아래 절차에서 이 기능을
 자동 조치는 해당 runtime이 구현·조합된 제품에서만 실행한다. 현재 reference
 primitive를 coordinator 완료 증거로 사용하지 않는다.
 
+
+## OPFS 보상 실패와 reconcile (STO-01)
+
+`put()`이 실패했는데 보상 cleanup effect가 확인되지 않으면 runtime은 실패를
+`OBJECT_RECONCILE` / `CONFLICT`(recovery `RETRY`)로 보고하고 journal row를 남긴다.
+이는 결함이 아니라 설계된 상태다.
+
+1. journal에 `PREPARING` 또는 `FILES_READY` row가 남아 있는지 확인한다. 남아
+   있다면 staging bytes가 아직 존재할 수 있다는 뜻이다.
+2. `maintenance.reconcile()`을 실행한다. reconcile은 같은 exact physical
+   generation token만 삭제하고, effect가 여전히 `EFFECT_UNKNOWN`이면 journal을
+   유지한 채 다시 `OBJECT_RECONCILE`을 반환한다.
+3. journal row를 수동으로 삭제하지 않는다. row가 사라지면 stale staging을 추적할
+   근거가 사라지고 quota만 누수된다.
+4. OPFS root나 journal database를 통째로 삭제하거나 schema를 downgrade하지
+   않는다. rollback은 새 v2 write admission을 닫고 v1+v2 reader를 유지하는 것으로
+   수행한다.
+
 ## 1. 공통 원칙
 
 incident 중에도 다음 작업은 금지한다.