Fuse jit_decode_u00() into jit_unescape() and surface a failed block manifest

[fdaviddpt]

Summary

jit_decode_u00() ran as a second awk pass after jit_unescape() had already collapsed
an entry own escaped backslash back to one literal backslash. That meant ordinary
prose in an entry body, shaped like a JSON control-byte escape, became byte-identical
to a genuine encoder-emitted escape once the first pass had run -- jit_decode_u00()
then collapsed both cases the same way, shrinking the block by five bytes and desyncing
it from the hook own byte-length manifest. The manifest check failed and the whole
thing fell back to the pre-#219/#223 forgeable splitter, through ordinary prose alone,
no adversarial payload needed. Closes #226 by fusing both passes into one left-to-right
walk (jit_unescape_blocks()) so the ambiguity never arises.

Separately, jit_blk_manifest_ok (the flag jit_split_ctx_blocks() already computed) was
read by nobody, so a failed manifest verification degraded silently in both consumers.
That silence is why #226 shipped green in the first place. Closes #227 by making both
consumers read the flag: jit-match.sh (must never fail hard) names the degrade as a
notice; jit-dry-run.sh (must fail loudly) prints a NOTE and moves off exit 0.

A third fact turned up during the #227 review, out of scope for this PR: pre-tool-hook.sh
and pre-path-hook.sh never build a manifest at all, only pre-prompt-hook.sh does. Naively
gating the #227 fix on the bare manifest-ok flag reported every genuine tool/path match as
could-not-evaluate -- caught by a large existing-test regression before it shipped. Worked
around with a second flag, jit_blk_manifest_seen (1 iff a manifest header was ever present),
so this PR does not regress the existing suite. The deeper gap -- extending #219 own
manifest-producer mechanism to those two hooks -- is filed separately as its own issue
rather than folded in here, since it is a materially bigger, separately reviewable change.

Self-review (Explore + oss:auditor, spawned concurrently) found two things, both fixed
in this PR: a stale comment in jit-match.sh still naming the deleted jit_decode_u00(),
and no automated test for the #227 notification path in either consumer (proved by
hardcoding both gating conditions false and getting a fully green suite) -- fixed with
tests/test-manifest-desync-227.sh, confirmed red against the pre-#227 commit.

Test plan

• Reproduced jit_decode_u00() runs after jit_unescape(), so ordinary entry prose desyncs the block manifest and both consumers fall back to the forgeable splitter #226 against the actual pre-fix scripts (0 entries matched / 1
  unverifiable via jit-match.sh; a forged entry name printed at exit 0 via
  jit-dry-run.sh), confirmed green after the fix
• Reproduced jit_blk_manifest_ok is set by common.sh and read by nobody, so a manifest that failed to verify degrades silently in both consumers #227 own silent degrade by forcing a manifest verification failure in a
  scratch copy of common.sh and driving the real, unmodified jit-match.sh and
  jit-dry-run.sh against it -- now pinned as tests/test-manifest-desync-227.sh,
  confirmed red against the pre-jit_blk_manifest_ok is set by common.sh and read by nobody, so a manifest that failed to verify degrades silently in both consumers #227 commit and green against this branch
• Confirmed a manifest-less match (pre-tool-hook.sh and pre-path-hook.sh own
  pre-existing gap) stays clean at exit 0, so jit_blk_manifest_seen does its job
• bash tests/run-all.sh -- 46/46 suites green, run four times over the course of
  this change
• python3 .oss/assemble_changelog.py --check -- ok, 26 fragments

Verified by the maintainer

The fix, checked against my own fixture rather than the branch's tests. I reproduced #226 independently before filing it; re-running that same fixture against this branch:

• jit-match.sh → 1 entry matched, exit 0, and the match is tricky.md — the genuine entry. The forged # Vocabulary: billing.md (matched: billing) stays inside tricky.md's body as prose instead of being promoted to a second match, and the six-character JSON control escape survives literally as prose.
• jit-dry-run.sh --prompt "tricky situation" → tricky.md(WHOLE BODY). Before this branch it printed billing.md(WHOLE BODY) at exit 0 for a keyword that was not in the prompt.

That is the class closed, on the exact input that opened it.

Red re-run against 408990d, each changed suite dropped in alone:

Suite	On main
test-manifest-desync-227.sh	exit 1, 3 failures — #227's degrade is genuinely unobservable there
test-block-framing.sh	exit 1, 4 failures — the new #226 cells
test-pre-prompt-hook.sh	exit 1, dies at the new #226 section; 126/126 and 199 lines on this branch against 108 lines on main
test-jit-dry-run-report-forgery.sh	exit 0 — correct, its diff is a comment and one assertion message, no behaviour

One thing to know about that third row rather than discover later: on the pre-fix code that section terminates the suite instead of printing a FAIL. run-all.sh still catches it — the exit code is non-zero and honest — but the log shows a section header and then nothing, which reads like a truncated run rather than a failure. Not blocking, and not worth a separate issue, but it is the one place in this diff where a red is quieter than the convention here asks for.

Blast radius against 408990d: 11 files — the three scripts, four suites, README.md, and three changelog fragments including the correction to changelog.d/223.fixed.md's now-false claim. Nothing outside the hooks lane.

On the adjacent finding, which I have filed as #230 and am not blocking the tag on. Verified independently: grep -ln 'JIT-CTX-BLOCKS' scripts/*.sh returns common.sh, jit-dry-run.sh and pre-prompt-hook.sh only; the count in pre-tool-hook.sh and pre-path-hook.sh is zero. So the manifest has one producer and the other two hooks always take the forgeable fallback. forges is a blocking row and I am shipping 0.6.0 over it anyway, because the defect is pre-existing — v0.5.0 has it, this release neither introduces nor widens it, and the tag is not the mechanism by which it takes effect. Blocking would leave users on a version with this gap plus the one #226 closes. That is a judgment against the letter of the ranking table and it is reversible: #230 carries the argument and the priority.

jit_blk_manifest_seen is a workaround and the PR says so, which is the right call. Gating on the bare flag would have reported every genuine tool/path match as could-not-evaluate — the cascade is what found #230. Removing the second flag belongs to #230's fix, not here.