A size guard that measured the tool, not the file
The guard only ran on Write. The identical body landed
friction-free through Edit, so what it actually gated was tool
choice. Change the inputs and compare the two columns.
before
after this PR
Three defects, one guard
1. It sized the tool, not the file.
Only Write was checked, so an over-cap file could be grown
indefinitely one Edit at a time. The fix projects the
post-write body: for Edit it reads the current file and applies
the replacement before measuring.
2. It was un-satisfiable on the files
it most wanted smaller. Comparing only against the fixed limit meant
a 458-line file could not be rewritten to 400 any more than to 600. The only
way to comply was to stop using Write. Now a call that shrinks
an already-over-cap file passes.
3. It denied where it should ask.
Crossing the limit can be a deliberate, informed choice. A hard deny repeats
the #2947 display-lint mistake: block correct work, and the lesson the user
learns is the escape hatch. It now returns ask, matching the
sibling context-file-budget-guard.
old_string that does not match all return null and
the guard stands aside. A guard must never block on its own failure. Issue
#3552.