Resolves #16949

providerResidency: null and providerActivity: null — per unobservable key, and across every service when the intersection is zero — for the life of a deployment, with nothing in the artifact saying why. This is FIX-4 on the #16706 ledger — the waiting-vs-broken consumer class — and it is our defect, not the escalated plane's.

Evidence: L2 (unit execution + three mutation receipts) → L2 required. Residual: none.

The defect

isProviderResidencyServiceKey() is only ever evaluated against a serviceKey the bridge already enumerates. So a residency key outside allowedServices is unreachable by construction — the predicate cannot return true for that key, which contributes nothing while any enumerated peer keeps observing. Only a zero intersection makes collectProviderResidency() and providerActivity (same gate) absent across every service.

Nothing throws. The pair reports exactly the value a correctly-configured non-provider container reports.

Measured on a live plane during the escalation:

allowedServices              : chroma, kb-server, mc-server, fleet-server, orchestrator
providerResidencyServiceKeys : local-model, model     (leaf default)
running                      : …, local-model (healthy 22h), ingress
intersection                 : EMPTY

docker-compose.local-agent-os.yml:68-69 is how it arises — a YAML anchor binds the bridge's observation set to the orchestrator's runtime-access set. That alias is deliberate, not accidental DRY: a comment directly above it reads "This profile uses host LM Studio, not the optional local-model container. Monitor only the Compose services it actually starts." The profile is correctly expressing scope — which is precisely what makes the resulting null a permanent steady state rather than a misconfiguration anyone would eventually notice.

Three maintainers spent a morning attributing a configured absence to a sick provider, because the artifact could not tell them which null it was.

The fix — both changes are about what a READER outside the process can see

1. providerResidencyEligible is emitted on the service record. It was already computed and passed into diagnose(), then discarded — so every external reader had strictly less information than the producer. It is the only thing separating never eligible, by design from asked and got nothing.

2. bridgeConfig.unobservableResidencyKeys publishes the keys the enumeration does not cover. The misconfiguration becomes a stated fact rather than a two-list intersection the reader must perform — which is exactly the derivation nobody performed for seven weeks.

Deltas

The dead-looking guard is RETAINED, and finding out why is the useful part of this PR. I removed if (!result) return null from collectProviderResidency() believing it unreachable — probeProviderParallelModelCapacity has five exits, three throws and two object literals, so the shipped probe cannot return falsy. Then the spec's own default surfaced it: providerResidencyProbe = async () => null. The seam is injectable and the branch is reachable through it. Without the guard, a null probe spreads into {...null, targetIdentity} and emits a degenerate record claiming an observation nobody made. Restored, with a comment stating which meaning is reachable where.

That is the same defect this PR fixes, one level up: I read the production producer and bound the conclusion to a surface that also has a test producer. Worth stating plainly given the ticket is about exactly this class.

The ticket proposed refusing at config time; this publishes instead. A residency allowlist naming an unobservable service is a misconfiguration, but the bridge is an observation lane whose contract is to degrade rather than fail — refusing to boot the snapshot over a diagnostic-field mismatch would trade a readable gap for an unreadable outage. Published in bridgeDiagnostics where the reader diagnosing the absence actually looks; a log line is not reachable from the snapshot they are holding.

The compose alias is not fixed here because it is not a defect. My original premise — that the alias was accidental coupling to split — was falsified by the comment two lines above it, and #16949 is truth-folded accordingly. What ships here is the whole fix: the bridge can now say which null a reader is looking at, on a profile where that null is permanent by design.

Test Evidence

npm run test-unit -- unit/ai/daemons/orchestrator/services/DeploymentStateBridgeService.spec.mjs
  74 passed   (72 pre-existing + 2 new)

npm run test-unit -- unit/ai/daemons/orchestrator/
  1443 passed

Mutation-differential:

The first mutation attempt was invalid and I caught it by checking the baseline. A 12-space replace pattern matched inside the 16-space diagnose() input line first, so it removed the wrong occurrence and reddened two unrelated diagnosis tests. Clean origin/dev runs 72/0, which is what exposed it. Re-run with a unique multi-line anchor, the receipt is exactly the two new tests. Recording it because a mutation that reddens something looks like a passing receipt.

What this does NOT establish

• It does not make residency work anywhere. It makes the absence readable. A plane whose lists are disjoint still reports null — it now also reports why, and names the keys.
• It does not validate the probe. Untouched; this is about whether it is ever asked.
• unobservableResidencyKeys is computed from the enumeration at snapshot time, so a service that stops being enumerated changes the field without any config edit. That is intended — the question is "can the bridge see this key now" — but it means the field is not a config audit.

Post-Merge Validation

• Nothing outstanding. On the next snapshot from any plane, bridgeDiagnostics.bridgeConfig.unobservableResidencyKeys answers the question that took three maintainers a morning, and providerResidencyEligible on each service record separates the two nulls.

Commits

• 57f26558ad — emit the discriminator, publish the unobservable keys, retain and explain the guard

Authored by Ada (Claude Opus 5, Claude Code). Session 87f453f9-aa80-4487-9ed1-b5d91e052c43.