Resolves #16485

The heap-ceiling fixture proved the member could be written, not that the override resolves — and it proved it by mutating the shared AiConfig singleton, the mechanism behind the #12335 orphan incident.

Evidence: L2 (both hops driven through real objects in a fresh process; three mutation receipts) → L2 required. Residual: one pre-existing suite flake, unrelated and characterised below.

Why the old fixture could not make its own claim

saved = AiConfig.orchestrator.supervisedTaskHeapMb;
AiConfig.setData('orchestrator.supervisedTaskHeapMb', INJECTED);   // beforeEach

The leaf resolves through its env layer at config construction — metadata.parse receives the env var's name and reads it itself. Writing the member afterwards exercises a different path than any deployment does. The afterEach restore bounded the blast radius; it did not make the setup correct, and the mutation was invisible only because nothing else in the file happened to resolve config inside that window.

The witness

A fresh process (fixtures/heapCeilingEnvWitness.mjs) whose env carries NEO_SUPERVISED_TASK_HEAP_MB=777 before any canonical import, so the value arrives the way a container does. Nothing is stubbed but spawnFn; both hops are read off the real objects — the Orchestrator's construction seam and runTask's composed child env. It emits one JSON line; a spawn or boot failure fails the test, with no in-process fallback, because degrading to setData on a bad day would restore the defect silently.

NEO_AI_ORCHESTRATOR_AUTHORITY_PROFILE is supplied the same way. It is read during Neo.create's config processing — before any instance field a caller could assign — and its leaf default is the empty string the profile assertion rejects. Reaching for setData there would have reintroduced exactly what this removes.

Deltas

Delta 1 — the ticket's stated trap is stale, and I derived the values instead of re-pinning them. It says FALLBACK_SUPERVISED_TASK_HEAP_MB and the leaf default "are both 384, so 384 cannot be the fixture value." Measured: the fallback is still 384 (ProcessSupervisorService.mjs:36), the leaf default is now 1024 (configBase.mjs:1115). A hard-coded premise had already gone stale without ever failing — so both forbidden values are now read live: the fallback through buildSupervisedTaskEnv({}) (the real function, not a copy of its constant), and the leaf default from this process, which carries no override. 777 remains valid against both, and the premise now fails if either moves.

Delta 2 — the reads are thunks, not consts. A describe body runs at collection time, before any test and before the suite's fixtures. Capturing a config leaf there is the module-load capture this repo has been burned by. Nothing forced this — it is the correct shape regardless.

Delta 3 — the AC anchors moved, in both files. AC-F1 (configBase.spec.mjs:53) and AC-F2 (Orchestrator.spec.mjs) both named parent #16463, which stays open for its L4 half; the coverage they label was delivered and closed by #16480. Retargeted, so following an anchor no longer lands on scope unrelated to the test in front of you.

Test Evidence

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

npm run test-unit -- unit/ai/configBase.spec.mjs unit/ai/daemons/orchestrator/Orchestrator.spec.mjs
  93 passed

Mutation-differential. The suite carries a pre-existing flaky pair (below); it appears in every arm including the unmutated baseline, and is subtracted here.

Row two is the receipt the ticket names explicitly — "and only that one" — and it holds. Row one reddening both is correct rather than sloppy: a zeroed first hop necessarily starves the second. Row three is the control that the witness is doing real work: with the override gone, every assertion in the block fails, so none of them can be passing on a default.

A pre-existing flake I did NOT introduce, and did not fix here

Two tests in this file — chroma max-runtime recycle (#12138) › defers an over-age chroma recycle… and › does not start pending chroma defrag… — fail on origin/dev itself.

I nearly mis-attributed this to my own change. A single clean-dev run came back green, which is exactly the trap; running both arms five times each is what settled it:

Sharpened further: with /tmp/orchestrator-test emptied first, the first run is green and every run after it fails, on dev and on this branch alike. The spec leaks per-run heavy-maintenance lease files (2,767 had accumulated locally since Aug 4) and the next run reads them. CI starts from a clean container each time, which is why it is green there and why this has gone unnoticed.

Out of scope here and not fixed in this PR — a different defect from the one #16485 names, and folding it in would make this PR's close target untrue. Reported separately for whoever owns the lane.

What this does NOT establish

• One override, one leaf. The witness proves this leaf resolves through its env layer; it says nothing about other leaves' parse hooks.
• Not the L4 half of #16463 — live survival, retained-set, steady-state concurrency — which stays open and untouched.
• No production change. ai/ is untouched by this PR; the mutations above were applied and reverted, never committed.

Post-Merge Validation

• Nothing outstanding. The witness runs in the ordinary unit suite from this merge onward.

Commits

• 155a09951a — the fresh-process witness replaces the singleton mutation
• 6f1e830487 — AC-F1/AC-F2 anchors retargeted to #16480

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