CADR-WEB-303 C-M10 private disk overlay reimplementation specification

C-M10-IDB-v1 durable-selection adapter

C-M10-IDB-v1 is SRC-M10-IDB: a browser adapter in cadr-m10-indexeddb.mjs, not a second COW planner. SRC-M10-CTRL first constructs and validates the candidate pages, nodes, and complete manifest. The adapter copies those supplied immutable bytes before any asynchronous operation, verifies their content-address keys, then stages only pages, nodes, and manifests. The selected base is never supplied to or retained by this adapter.

Each disk UUID has one derived IndexedDB database name; a handle for one UUID cannot address another UUID's meta, head, activation, or quarantine records. A database contains only the closed records m10-meta, m10-pages, m10-nodes, m10-manifests, m10-heads, m10-activations, m10-quarantine, and m10-refs. Schema 3 upgrades the exact schema-1 and schema-2 database names in place. A schema-1 upgrade requires the complete canonical pre-reference store set, creates only m10-refs, and writes refHighWater: "0". A schema-2 upgrade retains the same stores and high-water only when m10-refs is empty. A nonempty schema-2 reference set aborts the version-change transaction without rewriting controls or references. Schema 2's public IDs contained a kind; translating a live record to the schema-3 key would strand the owner that still holds its old cleanup ID, and this closed schema has no alias or tombstone/reconciliation record with which to preserve idempotent release. This is a selected safety boundary for an unpublished candidate schema, not a claim that a deployed format can be upgraded automatically. Before that rejection, the upgrader validates every schema-2 record, requires every sequence to be at or below the persisted high-water, and rejects a sequence used by more than one kind; malformed or collision-bearing input also aborts. A schema-3 reference has exactly key, diskKey, kind, rootSha256, and canonical decimal creatorSession; a snapshot's creator session is nonzero, while durable clone/export records use zero. Its public ID is exactly lowercase-disk-uuid-hex ":" canonical-positive-decimal-u64; it contains no kind. Kind remains a closed stored record field, so a kind-tagged schema-2 spelling is malformed at the schema-3 public boundary rather than an alternative idempotence key. An absent, malformed, or noncanonical source-schema control or reference record aborts the upgrade. Byte-bearing records contain an ArrayBuffer copy and an exact lowercase hash key; control records reject unknown fields, noncanonical decimal u64s, unexpected UUID bindings, or noncanonical activation keys. Opening requires the exact sorted object-store set and requires every store to have the string key path key, autoIncrement false, and zero indexes. Missing or extra stores, a wrong key path, auto-increment, or any index reject and close the connection. Every adapter read-write transaction requests IndexedDB durability: "strict" and rejects if that transaction option is unavailable. A content-address collision requires byte equality. This is a namespace/immutability safety boundary, not a cross-origin access control replacement; browser same-origin policy separately confines another origin's IDB.

The adapter retains the selected 4096-record activation bound per UUID database. Recovery requests at most 4097 activation records and refuses an over-bound database. At the bound, publication prunes only the oldest unprotected record in that same database; it retains the current head activation and immediate predecessor, and refuses if neither can be safely removed. pinRoot(kind, exactRoot) accepts only a validated complete level-2 overlay root and persists a closed reference record with a disk-bound, kind-independent identifier. Its metadata high-water update and reference insertion are one strict transaction, so a failed insertion rolls both back and a released identifier is never reused. A review snapshot is a transient creator-session reference; clone and export are durable roots. unpinRoot(id) first validates an exact canonical same-disk ID whose sequence is no greater than the persisted high-water. It deletes a present record only in its legal current session, but a missing already-issued ID succeeds idempotently. Thus a completion-response loss after a strict delete cannot strand an otherwise opaque review lease; malformed, kind-tagged, future, and foreign IDs still reject. Durable compact marks the complete selected manifest lineage, every reachable node/page, and every durable reference root while holding the disk's writer lease. Its single sweep transaction rereads the exact writer epoch, pending generation, head bytes, and complete reference set marked earlier; it deletes only unreachable immutable objects if all still match. A concurrent writer, changed head, or changed reference set aborts the sweep. It deliberately does not truncate the selected lineage.

Every reopened durable handle advances the stored session high-water, purges every older-session transient snapshot, and clears the writer lease and any prior session's pending-generation reservation in one metadata-and-reference transaction before recovery. Clone/export roots are not purged. This is safe because publication clears the reservation in the same transaction that writes the new head and activation: a reservation left at reopen is necessarily pre-publication, while a completed publication already has a cleared reservation. Every public adapter operation rechecks that session after its asynchronous storage/hash work. Closing one handle marks only that handle closed; every subsequent operation through it rejects before durable mutation, and it does not close a newer handle's shared IDB connection. A version-change event closes the database and makes later handle use fail as a version-change error. An IndexedDB QuotaExceededError or aborted transaction is surfaced as a failed staging or activation operation; because a transaction contains the head, matching activation, and pending-generation clear together, it cannot report a partial new control pair. The quota branch is source-inspected but not capacity-exhaustion tested.

An overlay map is a three-level radix-256 tree. Its root is level 2, the next level is 1, and leaves are level 0. The index bytes of the 24-bit LBA select levels 2, 1, and 0 respectively. A zero 32-byte digest means absent. An absent mapping reads the immutable base page. The empty overlay nevertheless has one real, canonical level-2 zero-root node. A level-0 digest names an exact 1024-byte content page; upper-level digests name CDROVN1 nodes.

Invariants:

1. A page key is SHA-256 of exactly its 1024 page bytes. A node key is SHA-256 of all 8232 canonical node bytes. A manifest and head have the distinct trailer hash rules below. Every store reread MUST reverify the key/hash relationship.
2. No mapping may name an LBA outside the selected base range. A complete map walk MUST also reject an unreachable child prefix, wrong node level, wrong node prefix, a cycle, absent referenced object, or wrong content hash.
3. A page equal byte-for-byte to its base page MUST be represented by an absent leaf, not a duplicate stored page. Removal prunes empty non-root paths; if the whole map is empty the canonical real zero root is used.
4. high_water reserves monotonically increasing unsigned-64 generations. Gaps caused by a failed transaction are legal. A writer epoch is a separate monotonically increasing u64; a stale epoch MUST NOT write a head.
5. Every successful open issues a monotonically increasing per-open session token. A new open invalidates all API objects and leases from the prior session. This fence applies to reads, writer operations, commits, pins, collection, and reopen, not merely to head publication. A read MUST recheck its token after every interleavable await and immediately before returning bytes. A pin MUST recheck after every tree/hash await and remain valid through its synchronous reference publication linearization point. Once the exact owned reference is retained, its ID MAY be delivered even if reopen invalidates the old session before the outer result await resumes; pre-publication invalidation still rejects without a pin.
6. Root mutation and collection coordination is backend-global, not per disk. Every initialize, reopen, commit, pin, or unpin advances one root epoch and invalidates any collector derived from an older epoch.
7. Initialization reserves the disk UUID's canonical stored record before its first await in explicit INITIALIZING phase. Reopen rejects that phase even if a head and activation have already been published. A concurrent same-UUID initialization likewise rejects and cannot return a detached handle whose runtime later diverges from the stored record. After recovery, session high-water, and metadata commit succeed, initialization synchronously changes metadata and the exact record to OPEN immediately before returning its handle. Any earlier failure removes the reservation, runtime, head, activations, metadata, and owned references if and only if the reservation is still the same canonical record in INITIALIZING; unreachable content-addressed objects may remain collection candidates.
8. A process or reload loss while acquiring or holding a review snapshot leaves no retained transient reference after the next successful open: its session transition atomically makes the new session authoritative and purges older snapshots. An explicit clone/export root remains reachable across that transition.

Browser controller and guest completion

cadr-m10-controller.mjs is SRC-M10-CTRL. It acquires the durable writer lease before loading the verified active closure or planning any mutation and retains that lease through planning, staging, guest completion, and publication. It applies strictly ordered 1024-byte writes to the three-level radix tree, compares every changed page with the independently supplied immutable base callback, and produces only changed pages and COW nodes. It asks the durable handle to stage and reread the page/node/manifest closure before invoking the worker's existing host-complete operation. Only after that guest completion succeeds does it ask IndexedDB to publish the new head and matching activation.

If staging or validation fails first, the guest receives failure and the old head remains authoritative. If publication or its reread fails after host-complete advanced the guest, or if its response is lost after the request may have reached the worker, the controller enters IN_DOUBT, closes the durable handle, terminates and replaces the worker through its required callback, and permits no further disk operation until recover reopens and rereads the durable store. The bridge implements the existing block-read and block-write host-request framing; it adds no worker protocol branch and does not duplicate guest disk-controller state.

Snapshot-review authority

claimSnapshotReviewAuthority() is a one-claim controller capability used by the M10 review path. The frozen authority exposes only branded acquire() and revoke() methods. A successful acquire pins the current complete active root, then rereads the same generation, head sequence, manifest hash, and root hash before returning a frozen lease containing that canonical binding and release(). Neither public object contains a durable handle, an adapter method, or a root-reference identifier.

The controller synchronously fences write, export, compact, recover, open, and close while acquisition or a lease is live. Acquisition continuity failure after pin invokes opaque compensating unpin. If that cleanup also fails, no lease has been exposed; the same branded authority enters RECOVERY_REQUIRED, and its next acquire() retries the opaque cleanup through a fresh durable session before it performs a new acquire. A lease-release failure similarly preserves the mutation fence until an explicit release() retry succeeds. Because IndexedDB unpinRoot treats only an exact, already-issued same-disk ID as idempotently released, a transaction which committed but lost its completion response closes on that retry without accepting forged or future identifiers.

An ambiguous guest-completion response is an emergency fence and therefore outranks an already-held review lease. The controller changes to IN_DOUBT, detaches and closes its durable handle, and starts exactly one worker replacement without waiting for a prior release() transport promise. The frozen lease and its opaque pin remain live; its next explicit release() captures its exact release-attempt number, ambiguity epoch, and replacement-flight identity before its first await. A fresh-session retry awaits that captured flight rather than a mutable controller-global flight, reopens only after it succeeds, and rechecks all three captured identities after reopenDisk returns. If another ambiguity superseded the attempt while reopening, the returned stale handle is closed and the retry rejects without installing that handle, unpinning, releasing the lease, or changing IN_DOUBT to CLEAN. The final current retry remains IN_DOUBT through its fresh-session durable unpin and reaches CLEAN only after that unpin and the same fence recheck succeed. If an old-session unpin was already pending, its attempt token is superseded: it cannot later change lease state, and it cannot block a fresh-session retry. This is an inferred safety rule of the selected reconstruction, not a claim about CADR or LMFS. Synthetic bridge tests exercise read, unsupported-operation, and an injected already-permitted write completion response loss under a held lease; they require IN_DOUBT, one replacement, one transmitted completion, retained pin before release, and a reopened session for release. Separate adversarial cases leave the old unpin unresolved indefinitely and gate both a retry reopen and a superseding replacement; they require the stale reopen to close, no unpin before the exact replacement completes, exactly one replacement for the superseding ambiguity, and CLEAN only after the final fresh unpin. That final boundary retires the completed controller-global join marker, so a later ambiguity in the restored clean controller starts its own replacement rather than joining obsolete recovery work.

If a replacement flight fails, its rejected exact flight likewise retains IN_DOUBT and the opaque pin: the affected release cannot reopen or unpin through a failed replacement. A later ambiguity notification may establish one new replacement flight; only an explicit release retry captured against that new flight can continue. This is also an inferred recovery rule and is covered with a synthetic failing replacement.

The disposable Chromium runner binds every CDP call to its single campaign deadline. A CDP socket error or close rejects every pending request, and a silent request rejects when the remaining campaign time expires, so the polling loop cannot wait past its own bound. The runner owns Chromium as a detached process group; its cleanup uses bounded SIGTERM, escalates to SIGKILL, and treats a surviving group as a campaign failure. Unit tests use hostile socket doubles and the process-group supervisor's escalation fixtures; the unchanged eighteen-scenario Chromium campaign remains the browser persistence evidence.

The controller-local mutation owner also serializes recover and close. Either operation rejects while planning, commit, import, discard, export, clone source capture, or compaction is active. recover retains that owner across the entire durable reopen, so a new mutation or close also rejects until recovery finishes. close never silently races an operation whose callbacks may still run.

CDROVN1 radix node

CDROVN1 is exactly 8232 bytes: 40 header bytes plus 256 32-byte child digests. There is no room for an in-record digest; the object address is SHA-256 of all 8232 bytes. This follows directly from the selected size and fields (DEC-M10).

For level 2 the prefix MUST be zero. For level 1 it MUST have its low 16 bits zero; for level 0 its low 8 bits zero. The child at index i of an upper node has prefix parent-prefix OR (i << (level * 8)). A complete walk applies the base LBA bound at the level-0 child, not merely the nominal 24-bit address space.

CDROVM1 complete manifest

CDROVM1 is 352 bytes: a 320-byte header followed by SHA-256 of bytes 0..319. Only the COMPLETE flag (1) is legal. The fields below are the frozen Phase 1 candidate offset table chosen under INF-M10: the reviewed decision selected all required fields and sizes but did not assign their offsets. Any change requires a new schema or selected profile; an implementation MUST NOT silently reinterpret bytes written under this profile.

Generation zero is the genesis manifest: both parent generation and parent hash are zero. A later generation MUST name an older generation and a nonzero parent manifest. Opening verifies the entire parent generation chain and validates the current manifest's exact reachable map count. The manifest records lineage only; it does not encode a separate delta list. Phase 1 retains that complete ancestry as a collection root. It implements no history compaction or parent-chain truncation. A future compactor must define a separately activated baseline and compatible lineage rule under a new profile before it can discard ancestors.

CDROVH1 active head

CDROVH1 is exactly 296 bytes. Its final 32 bytes are SHA-256 of bytes 0..263. All fields and offsets in this table are DEC-M10.

The initial head has a real activated generation-zero manifest and head sequence 1. An absent previous record has all-zero previous fields. A later head may name generation zero as its nonzero previous manifest; therefore generation number zero alone does not indicate absence.

CDRM10W1 snapshot binding wrapper

The safe selected wrapper is implemented in cadr-m10-wrapper.mjs. It is a 256-byte header followed by a complete CDRM5WK1 version-3 envelope described in the M5 scheduler specification. Before any asynchronous hash or semantic validation, the wrapper implementation copies the complete supplied wrapper/M5 bytes and validates and emits only that immutable candidate. A validator receives a separate copy and cannot alter the candidate through its argument or a closure over the caller's original buffer. The wrapper parser verifies the inner magic, version, flags, raw length, control witness invariants, and M5 envelope hash. It also structurally validates the selected CDRSNAP1 minor-2 header, fixed profile/artifact hashes, sorted contiguous chunk directory, required chunk set, chunk hashes, and final body hash. It then MUST invoke a supplied worker/core semantic validator and accept only an exact true result. Serialization and parsing fail closed if that validator is absent. Calling the existing worker validator directly is deferred to the integration owner; the Phase 1 module does not duplicate that semantic decoder or claim integration. Directory ordering matches the selected core: the first entry has no predecessor, so optional type 0 with flags zero is legal there; every later type MUST be strictly greater. Required types 1 through 10 remain present exactly once with required flag 1.

cadr-m10-overlay-export-v1 interchange

The implemented interchange is canonical UTF-8 JSON with an outer {body,sha256} envelope. sha256 covers the byte-exact canonical body. The body binds the schema, source disk UUID, selected base/profile/artifact hashes, source generation, entry count, root hash, and sorted unique page and node arrays. Each object carries lowercase content hash and lowercase exact bytes. The parser limits the complete archive to 320 MiB, rejects unknown fields, duplicates, reordering, malformed hex, hash mismatch, wrong node level/prefix, cycles, aliases, missing children, unreachable extra objects, and a tree count different from entry_count. Import never imports source head, activation, session, writer, or generation-control records; it publishes a fresh manifest in the destination UUID namespace.

This is an INF-M10 clean-room browser interchange, not a historical CADR format and not the previously sketched binary archive.

Deferred binary CDROVL1 archive

CDROVL1 is not implemented. DEC-M10 fixes its 320-byte header, then N * 64 sorted directory entries and payloads, followed by a final hash. A directory entry is (kind u32, flags-zero u32, offset u64, length u64, sha256[32], reserved-zero u64), sorted by kind and hash; the archive contains exactly the reachable closure and has a 320 MiB maximum. Its header offsets and digest binding were not selected, so implementing a codec would falsely invent an interchange format.

TODO-RUNTIME-M10-CDROVL1-HEADER: obtain a reviewed header offset/digest table only if binary CDROVL1 interoperability becomes a separate selected profile, then add strict export/import codecs, malformed archive cases, maximum-size checks, and a closure comparison against the in-memory map.

Commit contract

Preconditions: the disk is writable, the caller owns the current writer epoch, the expected head sequence matches, each write has an exact 1024-byte page, and writes are in strictly increasing LBA order. Duplicate or unordered writes are rejected rather than made order-dependent. A backend accepts only one commit invocation at a time for a disk and rejects another immediately. Reopen is likewise rejected while the commit is active.

Required order:

1. Validate disk binding, epoch, head sequence, resource limits, write order, and every LBA.
2. Read each relevant immutable base page and convert byte-equal writes into map removals.
3. Build changed pages and exactly the affected COW three-node paths privately.
4. CAS-insert each page/node by hash and reread it with hash verification.
5. Cross the core-completion seam.
6. Publish the working root in DIRTY/paused runtime state.
7. Reserve a new generation from high_water; a later abort may leave this gap.
8. Build, CAS-insert, and reread a complete manifest.
9. Recheck the open-session token, writer epoch, expected in-memory head, stored head bytes, and identical current activation. In one non-awaiting logical action, replace heads[disk] and write the identical activation at activations[disk, head-seq].
10. Reread and verify the active head, manifest, root, and map; only then become CLEAN and report durable success.

The same current-head checks run after validation and again immediately before activation, after the last await or injected callback. The head/activation action is logically atomic in the deterministic backend: no callback or await separates its two map mutations. A production durable backend MUST supply an equivalent all-or-neither transaction. An error before that action leaves the old active head. Pages, nodes, a reserved generation, or a manifest may leak and are later collection candidates; they are not active state. If core completion already succeeded, that error produces the paused SAVE_FAILED state described above. An error at or after publication is uncertain: the caller MUST reread the head. If it names the new validated manifest, the operation reports durable success with recoveredAfterFault; otherwise it reports the original failure.

Immediately before that non-awaiting publication, the backend quarantines malformed records within an already bounded activation log and preflights one free slot. At the 4096-record boundary it preserves every open disk's current activation and immediate predecessor, proves sufficient unprotected candidates exist, then removes the oldest candidates before adding the new activation. It rejects without partial canonical-history pruning if no safe slot exists. Publication therefore cannot produce record 4097 and report a durable head that recovery categorically refuses to scan.

Every named transition has an injectable before-* and after-* seam: validation, base comparison, private build, page CAS, core completion, dirty publication, generation reservation, manifest CAS, head/activation, head reread, and clean publication. TEST-M10 runs a synthetic fault at all of them. This proves only the in-memory transition implementation, not loss behavior of IndexedDB, OPFS, browser termination, or an actual power source.

Browser durable-selection suffix

SRC-M10-IDB implements only the durable suffix of this transaction. Its caller first owns steps 1--8, reserves a generation through the adapter, and supplies a complete candidate manifest plus the immutable closure to stage. The adapter revalidates the candidate's disk/profile/artifact binding, direct parent, reachable node/page closure, entry count, session, writer lease, and expected active head. It then performs this browser-specific order:

1. before-stage; copy, validate, CAS-stage immutable candidate bytes; then after-stage.
2. Verify the candidate closure and reread current control state.
3. before-head-activation; boundedly preflight an activation slot.
4. In one IndexedDB read-write transaction, recheck the stored old head and its matching activation, then put the next head, identical next activation, and pending-generation clear. The transaction's completion is the publication point.
5. after-head-activation, before-reread-head, a fresh atomic control snapshot and complete closure verification, then after-reread-head.

The callback ledger is exactly before-stage, after-stage, before-head-activation, after-head-activation, before-reread-head, and after-reread-head. Hooks occur only outside an active IDB transaction. Therefore a callback hook cannot extend a transaction across an arbitrary callback: it observes either the pre-publication pair or the completed transaction. These hooks do not interrupt an outstanding request inside the publication transaction. A rejection before completion leaves the old selected head; a post-completion callback/re-read error performs the normal uncertain-result reread and returns durable success only if that reread names the new head.

TEST-M10-IDB ran a disposable Chromium 150.0.7871.124 origin both headed under Xvfb and headless against all six ledger seams. For each seam it separately injected an exception, terminated the dedicated worker at the parked hook, and reloaded the page; it also mutated the caller's candidate page only after commit had entered. Each restart saw exactly generation/head (0,1) or (1,2) with the original matching map root, never a head without its matching activation or a late-mutated page. After each of the nine pre-publication faults, a fresh reopened writer cleared the abandoned reservation, reserved generation 2, and durably committed head sequence 2. The same campaign retained a nonmutating canonical full-store hash for a second same-origin UUID database, reopened and reread an iframe's foreign-origin database, rejected real missing-store, extra-store, wrong-key-path, auto-increment, and indexed schemas, proved a stale handle's close() did not close the current handle or permit closed-handle metadata mutation, instrumented page-realm read-write transactions to require strict durability, forced fallback recovery from a corrupt current head while quarantining a forged high-sequence activation, and published at the real 4096-record activation boundary. It exported the exact empty active closure and removed staged unreachable page/node objects without changing the active generation. It also forced a same-origin IDB version upgrade to confirm that the old handle was fenced. The HTTP harness served only an exact preloaded fixture allowlist, validated Host, and returned 404 for GET and HEAD probes of repository-private and unrelated paths.

RUN-M10-KILL separately exercises the production controller and IndexedDB adapter inside a dedicated browser Worker. Its guest endpoint is an explicitly synthetic host-request protocol responder, not production cadr-worker.js or a running CADR Wasm machine. In addition to the six parked callback seams, synchronous probes post an out-of-renderer signal and enter Atomics.wait on a SharedArrayBuffer before returning from the IndexedDB transaction scheduler. The first stage request or head-publication metadata request therefore remains outstanding until the external supervisor kills the complete Chromium process group. Repeated campaign runs selected the complete old state at both outstanding-transaction barriers.

Before launching Chromium, the supervisor reads the selected base from a local path, requires exactly 269,562,880 bytes, independently computes the selected whole-image SHA-256, and refuses any mismatch. The isolated controller Worker then uses bounded HTTP Range requests for the actual base pages and obtains the verified identity from the host. The campaign no longer attests the selected hash while serving unrelated zero pages.

RUN-M10-KILL used a separate host process, not page script, to launch Chromium with a disposable persistent profile. At each of the six seams the page parked the durable operation, the host sent SIGKILL to the complete Chromium process group, waited for exit, restarted Chromium on the same profile, and reopened the complete closure. before-stage, after-stage, and before-head-activation selected generation/head (0,1); after-head-activation, before-reread-head, and after-reread-head selected (1,2). No run observed a mixed head/root/activation. The profile was removed after the campaign. This closes browser process loss and restart at the named seams. It does not place the kill inside an unobservable internal IndexedDB request, remove machine or storage power, test device-cache loss, exhaust quota, or use CADR media.

A later interrupted audit exposed a host-harness cleanup defect rather than a disk-format defect: Chromium had been launched as a detached process group, so an exception or abrupt supervisor loss during partial launch could leave that group alive after the evidence-producing command ended. The corrected supervisor owns a browser group from the instant it is spawned, cleans partial launches and every loop body in finally, bounds SIGTERM before escalating to SIGKILL, and uses a Linux PR_SET_PDEATHSIG wrapper tied to the exact Node parent. The wrapper remains the detached group leader while Chromium runs; parent death signals the wrapper, which kills the complete group rather than only Chromium's direct process. Process-tree tests cover parent death, an already-closed leader with a live descendant, a descendant that ignores SIGTERM, a live wrapper's bounded SIGTERM grace and escalation, and a process group that remains after final SIGKILL. The process-tree and static controls are verified. On 2026-07-30, two fresh invocations of scripts/run-cadr-m10-process-kill-browser.mjs against the resident-watchdog revision each produced old, old, old, new, new, new, old, old; after each ordinary completion, a process-table check found no matching Chromium or watchdog process and /tmp contained no cadr-m10-process-kill-* root. An abrupt signal or supervisor death can still leave that inert host directory for explicit cleanup, although the browser group is killed. These host-harness results do not strengthen the process-loss result into a physical-power claim.

Writer fencing and activation recovery

beginWriter issues a new writer epoch only when no lease is active. closeWriter releases it. Reopening first issues a new session token, advances the session high-water, and clears old leases and pending reservations, so every previous API object is stale before recovery awaits. A head records the epoch that published it, but a head sequence remains the optimistic commit comparison value. Exhaustion of any session, writer, generation, or head-sequence u64 fails closed; values never wrap.

Open/reopen uses the following defensive order:

1. Parse and hash-verify the current head; require the identical activation keyed by its disk UUID and head sequence; then validate its active manifest, lineage, root, and map.
2. If an intact current head supplies a valid previous binding, try that previous generation without treating a zero generation as absence.
3. Provided the backend contains no more than 4096 activation records total, quarantine malformed keys and records, then try canonical records for the disk in descending head-sequence order. Each candidate is reread by its exact key before use. Its outer key, UUID namespace, and sequence MUST equal the parsed head's UUID and sequence; a high outer sequence cannot promote lower-sequence head bytes. A key is exactly lowercase-disk-uuid-hex ":" canonical-decimal-u64, with a nonzero sequence. Malformed records do not stop a later valid candidate, but an over-limit activation volume refuses recovery rather than performing an unbounded scan.
4. If a fallback succeeds, retain the exact validated head and manifest bytes as a private read-only snapshot and expose only that snapshot in RECOVERY_REQUIRED; later active() calls do not return the corrupt current-head store. If none succeeds, refuse the mount. It MUST NOT manufacture an empty overlay.

This makes unactivated manifests deliberately unrecoverable: creation alone is not durable selection evidence.