Custody boot gate withholds fallback background refresh silently — no log, no sidebar signal

[iceteaSA]

Summary

packages/opencode/src/index.ts:2803-2810 decides at plugin construction whether to start fallbackManager.startBackgroundRefresh(). When it withholds, nothing observable says so — the process looks identical to a healthy one from outside.

const fallbackRefreshStructuralDark =
  getClaustrumMode(initialStorage) === 'claustrum' &&
  provisionalCustody.provisional === true &&
  (fallbackDimensions.fallbacks === 'M' || fallbackDimensions.fallbacks === 'R')

const fallbackRefreshReady = fallbackRefreshStructuralDark
  ? Promise.resolve('not-started')
  : fallbackManager.startBackgroundRefresh()

Why this is worth a gate rather than a review comment

A boot-time flag gating a resource fails loud — the acquire blocks or returns null, and something errors. A boot-time flag gating a capability fails silent: nothing errors, a manager simply never exists, and every downstream observation is merely quiet.

The right audit question is not "can this be wrong at boot" but "what does the process look like from outside when it is wrong" — and here the answer is identical to healthy. That is the property that makes it want an assertion rather than a review.

Evidence

'not-started' occurrences in index.ts .............. 1   (the assignment itself)
consumers of fallbackRefreshReady .................. 1   (__fallbackRefreshReady, a test export)
logger calls inside the gate block ................. 0
logger.{warn,info,debug}('claustrum', …) elsewhere . 16  ← the convention exists, this site opts out
sites referencing fallbackRefreshStructuralDark .... 2   (declaration + use)

So the withheld state reaches neither the log file nor the sidebar. The only consumer is a test seam.

Prior art in this repo

This is the same shape as the silent background-refresh swallow fixed in #233: ClaustrumCredentialCache.#refreshIfApproachingExpiry handled failures with void load.catch(() => {}) and zero logger calls, so a latched vault record produced no output at all while the cached token kept serving. That one only became visible at hard expiry.

There is also a live precedent for this specific gate going wrong. An earlier revision computed boot evidence as "every bound fallback has a usable resident credential right now", so a single cold account at boot returned provisional FAIL_CLOSED and suppressed startBackgroundRefresh() across all accounts — re-introducing a fleet-wide idle-expiry exposure. That was corrected to a structural-only gate, but the silence was never addressed: the corrected gate is still unobservable when it withholds.

Suggested fix

1. Log once at the decision, at warn, with the dimensions that produced it (mode, provisional, fallbacks) — matching the existing logger.*('claustrum', …) convention already used at 16 other sites.
2. Surface the withheld state in sidebar state so it is visible without reading the log.
3. Add a test asserting the log fires when the gate withholds, so the observability itself is pinned rather than assumed.

Not claimed

The gate's logic is not alleged to be wrong here — this is about the absence of a signal when it withholds. The entering-a-state circularity class (a transition reading the flag that says you are already in that state) was traced separately on the cache-connect path and is clean: ensureClaustrumCredentialCache has no mode read.