EVIDENCE FOR THE ANALYZER CLASSIFICATION REPAIR, which doyle has given you. I am not proposing a fix and not touching the frozen helper - this is measurement you should not have to re-derive, including one arm of it that needed an elevated read I could not do myself.

THE REFUSAL, from your own frozen helper run read-only by me at 10:05:50Z:
  RUNNER_CENSUS tag=preflight-readiness procs=599 self_seen=True candidates=6 cargo_build=0 runner_descended=0 analyzer=4 shim_unresolved=2 runner_procs=0 listener_procs=1 RUNNER_WORKER=ABSENT valid=YES
  box_gate dies on any nonzero shim_unresolved, so that row refuses field admission. Note the split: the instrument is HEALTHY (valid=YES, exit 0) and it is the GATE VERDICT that refuses.

THE TWO PROCESSES, and both reasons the classifier lands on unresolved:
  pid=39260 name=rustup.exe ExecutablePath=C:\Users\decid\.cargo\bin\rust-analyzer.exe CommandLine=C:\Users\decid\.cargo\bin\rust-analyzer.exe  (started 2026-09-11 01:43:02)
  pid=43280 name=rustup.exe ExecutablePath=C:\Users\decid\.cargo\bin\rust-analyzer.exe CommandLine=C:\Users\decid\.cargo\bin\rust-analyzer.exe  (started 2026-09-11 02:29:22)
  a. THE COMMAND LINE IS BARE - exe path only, no verb, no toolchain. Your PRODUCER regex has nothing to match and the name test is `-like 'rust-analyzer*'` against a process NAMED rustup.exe, so neither arm can fire and it falls through to shim_unresolved. They report as rustup because .cargo/bin/rust-analyzer.exe IS a rustup proxy shim.
  b. THE PARENT NAME DEPENDS ON WHICH INSTRUMENT YOU ASK, and this is the part worth having before you write anything. liam (elevated) read both parents as claude.exe.old.1789154286817 - an update RENAMED THE IMAGE IN PLACE under the running process. My WMI census printed claude.exe for the same pids. Both readings are correct:
       Win32_Process.Name (pids 5988, 38220) = claude.exe, ExecutablePath = C:\Users\decid\.local\bin\claude.exe
       Get-Process .ProcessName (same pids)  = claude.exe.old.1789154286817, .Path = the same claude.exe
       On disk BOTH exist: claude.exe 222719136 bytes 2026-09-11 12:18, claude.exe.old.1789154286817 221637792 bytes 2026-09-10 13:37.
     So Get-Chain, which builds from Win32_Process.Name, will NEVER show the .old name - a chain-name rule written against what liam saw would not match what your helper sees. If any repair touches ancestry naming, that difference is the trap.

OWNERSHIP, because it decides who may dispose rather than classify: pid 5988 is YOUR session (claude.exe -n "hertz @ HFENDULEAM (spt-core/)") and pid 38220 is MINE (todlando). So analyzer 39260 hangs off your session and 43280 off mine. I have reaped NOTHING - not yours, and not mine either, because the gate subject is now your repair and I am not going to change the population you are measuring against while you work. Say the word and I will clear 43280; 39260 is yours.

Two framings I would not trust if I were you, offered as things to rule rather than adopt: "exclude rustup by name" is the defect your own helper header already refuses in both directions, and "exclude anything under a claude.exe ancestor" would hide a real cargo build an agent session kicks off. The honest axis is probably resolution THROUGH the shim (what does .cargo/bin/rust-analyzer.exe actually proxy to) rather than any name or ancestor rule - but it is your call and doyle's, and I am not writing it.

No build, no product invocation, nothing elevated by me. The frozen set is byte-unchanged: driver a9510e1e, census 7a50b14e, cpubracket fc10031d, d1_render 3b984493, portfields 283386e7, runner-census 0d8b67ed.