opencode: assert the config hook actually puts vault material on the wire

[iceteaSA]

Closes #53. One test arm, and the mutation evidence narrows my own issue — reporting both numbers because the second one is the argument and the first one is against me.

What #53 claimed, and what the mutations actually showed

I wrote that "a config hook which installed a material-dropping closure would pass the entire suite". Two mutations, run against production code:

serve closure forwards the sentinel unchanged
  -> 18 failures: the new arm + 17 EXISTING
     serve.test.ts        12
     config-hook.test.ts   1   (reconnects after a transient connection failure and its backoff)
     freshness.test.ts     2
     lifecycle.test.ts     2

serve closure forwards an empty string in place of the material
  -> 1 failure: the new arm ALONE
     Expected `Bearer VAULT-MAIN-TOKEN-xyz`, Received `Bearer`

So for sentinel leakage the suite was already well defended — 17 arms catch it and my claim was too broad. For the empty-material shape, nothing caught it.

That second line is cortexkit/openai-auth#154's observed symptom reproduced character-for-character in this harness. There, a tombstoned main under claustrum mode emitted a bare Bearer: the vault cache.get succeeded and the credential was then discarded by a catch { /* use stale token on refresh failure */ } falling back to currentAuth.access ?? ''. A tombstone is precisely the state with no stale token, so that branch is correct for every non-custody case and wrong for exactly the one custody creates.

The one hook-level test that existed, and why it did not help

config-hook.test.ts already had an end-to-end arm — it installs the hook and calls cfg.provider.deepseek.options.fetch — and it caught the sentinel mutation. It asserts .status).toBe(200) and a detect count, and never reads the forwarded authorization header.

So the composition WAS exercised; what was missing is an assertion about the thing being composed. A stub upstream returns 200 regardless of what it was handed, which makes a status assertion structurally incapable of noticing an empty credential.

The arm

Installs the hook in the steady state (valid handle file + tombstoned auth entry), sends a sentinel-bearing header through cfg.provider[id].options.fetch, captures the forwarded request, and asserts three things rather than one: the header equals the expected material, does not still contain the sentinel, and is neither empty nor the bare string Bearer.

Verification

bash scripts/gate.sh exit 0, workspace floor 630 >= origin/master 630 at 636fe62, hermetic 222 pass / 0 fail, one file, 33 insertions, no deletions, Cargo.lock and bun.lock untouched, revert sweep clean.

The implementer's gate run went red on manifest_lock_aba_regression::reclaim_leaves_nonmatching_siblings_live_lock_and_other_manifest_quarantine at load [10.59, 5.90, 6.28] — the #51 class, in a file this diff does not touch. Mine passed at load ~5. Worth noting on #51 that this is a lower load than the [15.02] failure earlier today.

---

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

---

Summary by cubic

Adds an assertion that the config hook actually forwards vault material, closing #53. The sentinel-leak variant was already caught elsewhere, but no test caught a credential that had been emptied into a bare Bearer; the new arm captures the forwarded request and verifies the Authorization header carries the vault token, not the sentinel, and is neither empty nor just Bearer. Test-only change, no production code touched.

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