Exact-match change made and exercised. bf78d113 preserved as its own file, its receipt untouched; missing-byte rows stay labelled non-reproducible; no reconstruction, no capture-suite rerun.

FINAL PIN  d3/d3-emission-probe-v4.ps1  93ee37e1d2f36a6fca99807af26efec284c46abf3620572b8c16a8eb500bcc0a
DIFF  d3/d3-launcher-bf78d113-to-93ee37e1.diff  fd9a7e4b... (2 hunks, 17 added, 10 removed)
RECEIPT d3/d3-exact-match-receipt.md 5d8aec85...  MAP d3/d3-control-subject-map.md 2dac58b7...
CONTROLS d3/d3-guard-fixtures.ps1 4a759554... -> d3-guard-fixtures.out 0fe758e0..., 35/35
  by subject: 93ee37e1 30/30, bf78d113 2/2, 92e02907 3/3 (five predecessor arms, all red-on-purpose)

THE CHANGE. Tolerance gone from the identity decision. Three outcomes: identical ticks -> root_creation_EXACT_match, root_verified=True; differs but inside the band -> root_creation_NEAR_NOT_EXACT with delta_ticks printed, NOT verified, candidates UNATTRIBUTED; beyond the band -> root_pid_REUSED, NOT verified, candidates UNATTRIBUTED. The band is a REPORTING distinction only and the source says so at the constant. No termination authority follows from any list this walk prints; PENDING disposition and no-automatic-kill unchanged.

BOUNDARY FIXTURE, against the actual walk. Root row 6 ticks off the captured time - the real measured API discrepancy: v4 reports NEAR, delta_ticks=6, root_verified=False, observed=0, claimant UNATTRIBUTED. NEGATIVE CONTROL on bf78d113, same fixture: root_verified=True and the claimant attributed - the defect you named reproduces on demand. Exact arm: identical ticks verifies, and only then is a child attributed.

CONSEQUENCE YOU MUST RULE ON BEFORE D3 RUNS. v4 anchors on Process.StartTime and compares against a Win32_Process row. Measured here on an unmodified live process (own pid, -Filter by pid, no enumeration): StartTime 05:31:20.0668029Z vs CreationDate 05:31:20.0668020Z, delta_ticks=9. Two APIs do not agree to the tick, so on a REAL run root_verified=False becomes the normal outcome and a live PENDING report will list EVERY real descendant as UNATTRIBUTED. Safe and under-claiming, but the descendant observation D3 was asked to produce is effectively lost. Narrow fix if you want it back: anchor from the SAME SOURCE - capture the root's Win32_Process.CreationDate at launch. Measured: two Win32_Process reads of one pid, 200ms apart, same_source_delta_ticks=0, so exact agreement is attainable. That adds a process-table read on the launch path, which is more than the change you dispatched. NOT implemented. Your call.

EXACT PROPOSED D3 INVOCATION (ungranted; posted for admission only, nothing run):
  powershell.exe -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Bypass -File "<d3dir>\d3-emission-probe-v4.ps1" -RunId <nonce> -OutDir "<preserved>\d3\run-<nonce>" -ExePath "C:/Users/decid/Documents/projects/spt-core/.worktrees/304-w2-repr/target/release/spt.exe" -ExpectedSha256 72d309011415b419aabfdb0b4065df1183bfd0069a9f95b5779da62e43349b10 -DeadlineSeconds 60 -DrainSeconds 30
  Preconditions the invocation itself enforces: elevation present (refuses at :483 otherwise, exit 2), exe sha equals the pin (exit 2), the run-scoped broker name absent from the pipe namespace at the check with the absence instrument proven (exit 2). Preconditions it does NOT enforce and that the grant must carry: run it from an ALREADY-OPEN elevated console, never a fresh UAC relaunch - GetConsoleProcessList()==1 blocks the child on stdin and hangs an unattended leg. One execution, one nonce, no retry arm; OutDir under the preserved dir, never a scratchpad. It emits and CAPTURES the cleanup command; it never runs it, and the emitted bytes stay unpinned until you have decoded and reviewed them.

D3 still ungranted here: no product invocation, pipe enumeration, elevation or execution. Scheduling-driver work held. Idle.