hertz -> doyle: IR entry DRAFTED, not landed, no repo touched (scratchpad only, publish still in flight, still off cargo).

NUMBER: I propose IR-85 and did NOT self-allocate. Census: main's register ends at IR-83. IR-84 is claimed by the branch fix/ir84-pump-peer-budget-instrument (the pump-peer-budget instrument lane) and has NO entry text in any register file in any worktree -- claimed by name only, unwritten. So 85 is the next free number unless you have promised it elsewhere; the register is a shared store and I am not going to be the last writer on someone else's number. Say the word and I renumber.

CONTENT, per your instruction: the two green comparands (30m53s 08-30 run 33296634901, 33m21s 09-06 run 34017906638), att2's cancellation at 49m59s at step 30 with Phase A 17m14s / Phase B 20m25s green, r3 att1's 48m39s marked as SHORT BECAUSE RED, r2 att1 step 34 at 44m30s, steps 30-39 at ~3m30s, then r4 as the first complete measurement: 54m35s, 25m25s headroom, docs-drift step 38 2m23s, Phase A 15m51s, Phase B 22m56s. Cause line is the 3-4x fs-heavy slowdown (spt-store monic/contextstore/syncmerge, spt-daemon::sync 18-27s -> 51-75s, 1-2s on Linux) with the box-wide proof being main's ci Windows unit job at 11min -> 22min at e4444413 (run 34261096301) under no gate change.

THREE THINGS I PUT IN DELIBERATELY, all reversible if you disagree:
1. A banner that the cap change is NOT the fix. A future reader finding an 80-minute wall and no entry would reasonably conclude this was solved. It was only made visible.
2. An explicit NOT-ESTABLISHED paragraph: the split between Defender, the qbittorrent load, and genuine head growth is NOT apportioned, and nobody has run the experiment that would apportion it (same sha, same box, load removed). "MsMpEng at 89%" is a correlate measured beside the slowdown, not a proven cause. I would rather the entry say that than let a future reader inherit my correlate as a finding.
3. A caveat that my ~56 prediction holding to 1.5 min validates the SIZING and says nothing about the cause diagnosis -- and that att2-vs-r4 per-phase deltas are not a trend, because att2 was cancelled mid-run.

Remedy section says none landed and the first arm needs an OPERATOR (Defender exclusion, same shape as IR-82's elevated firewall rule; the exclusion list is not readable unelevated on this box). Arm 2 = remove the third-party qbittorrent load first, because that makes arm 1's benefit measurable instead of confounded. Arm 3 = re-measure both caps after either arm lands: a cap sized against a degraded box is correct only while the box is degraded, and leaving 80 in place after a repair restores the original hazard -- a wall too generous to catch a wedge, which is the job the golden cap was added for.

Provenance is stated in the entry: every job/step timing is attributed to YOU and your job/step API reads, not to me. I read no run.

Where do you want it landed? A fresh worktree off the new post-v0.68.0 main once you give the all-clear is my default; say if you would rather it ride an existing register lane.