test(custody): pin cross-tenant manifest isolation

[iceteaSA]

Tests only. No production change — this pins behaviour that is already correct but currently unasserted.

Why

opencode-handles.json is a shared, co-tenant manifest. Blocks are keyed by provider + serve; ours is anthropic / anthropic-auth. Sibling plugins own their own blocks and evolve them independently.

A sibling tenant is adding an optional minTtlMs key to the account objects in their block and asked us to confirm we tolerate it. We do — structurally:

• Reader — readCustodyHandles (packages/core/src/claustrum.ts:482) filters json.providers to entry.provider === provider at :501-506 before any account parsing, then selects on entry.serve === serve at :508. Foreign blocks never reach the account loop.
• Writer — writeCustodyHandleManifestEntryLocked :1424 passes foreign blocks through by identity (providers.map((p, i) => i === blockIndex ? {…} : p)), never re-serialising them from a parsed model.

Neither property was pinned by a test. Both are consequences of current statement order and object-spread choices. A refactor that validated accounts before filtering by provider, or rebuilt the providers array instead of mapping it, would silently make a foreign tenant's block reachable — or drop it — and nobody would find out until a live shared manifest took someone dark.

The tests

• reads our accounts while ignoring a foreign block with unknown account keys — a foreign block carrying minTtlMs beside ours; our read returns our accounts with corruptLabels empty.
• reads our accounts while ignoring hostile foreign provider entries — foreign accounts that is not an array, plus null, 42, and a {provider}-only object as siblings in providers[]; our read still succeeds.
• preserves a foreign block unknown key byte-identically when writing our account — writes a new account into our block and asserts the foreign block is serialise-identical afterwards.

Verification

Both mutations break the isolation, not the tests:

mutation	result
remove the provider and serve filters so the account loop sees a foreign block	reads our accounts while ignoring a foreign block with unknown account keys — Expected -7 / Received +1
writer serialises only our own block, dropping foreign ones	preserves a foreign block unknown key byte-identically when writing our account — Expected -6 / Received +6

My first attempt at the reader mutation was too weak and passed. Removing only the provider filter leaves the serve selector at :508, which still lands on our block — a no-op for this fixture. That was my mutation being wrong, not the test being vacuous; removing both filters reddens it. Worth stating because a mutation that fails to redden looks identical to a test that does not work, and the difference is which one you fix.

The write-status assertion in the third test is deliberately first, before any preservation assertion. writeCustodyHandleManifestEntry returns {status:'refused', reason} rather than throwing, so a round-trip test that skips that check reads the untouched original file and reports preservation that never happened. That is exactly how my initial hand-probe of this produced a false positive.

Gates: core 199/0 · opencode 1897/0 (1894 + 3) · typecheck clean.

Known limit, stated rather than implied

Our preservation is by construction, not by assertion — there is no post-mutate check that foreign blocks are unchanged. The sibling tenant's writer asserts it inside their locked write, so their regressions fail at the writer; ours would fail only at test time, once these tests exist. Converging on a writer-level assertion is the better end state; this PR closes the gap that is cheap to close now.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

---

Summary by cubic

Adds regression tests for cross-tenant manifest isolation in the shared opencode-handles.json. No production change; these assertions pin behavior that a refactor could otherwise silently break.

Tests

• Reader ignores a foreign block that carries an unknown minTtlMs key and returns only our accounts with no corruption.
• Reader also ignores hostile foreign entries: non-array accounts, null, a number, and a provider-only object.
• Writer preserves a foreign block byte-identically when writing our account, with the write-status check first so the round-trip assertion can't pass on an untouched file.

Known limit

• Foreign-block preservation is by construction, not asserted after the write; a writer regression would surface only at test time.

^{Written for commit 061657d. Summary will update on new commits.}