v4.100.106

Fixes

sed, grep and awk were guarding against a record nobody wrote to

The three POSIX tools added in 4.100.105 enforce read-before-write against the read
registry the SDK builds for them. The VS Code extension supplies its own read_files
and editor, which write to a registry of its own — so nothing ever wrote to the
SDK's, and every in-place sed was refused for a file the model had just read.

Measured on a live run of 4.100.105: six read_files calls on the target file, four
sed --in-place calls on the same path, and all four refused with "has not been read
in this session" — twice immediately after a read_files that the refusal itself had
asked for. The model then fell back to an editor call it had already sent, and the
repeated-call guard ended the session.

The registry now travels with the executors as a capability: a host that replaces half
the read-before-write guard hands over the record the other half reads. The CLI was
never affected — it takes the SDK's executors whole, which is why every test passed.

A sed row named no file, and its code block opened with ```undefined

Two faults on the same chat row. grep, sed and awk name their files under files,
which neither the path nor the paths lookup read — so the row named no file and fell
through to dumping the raw arguments. And the block it dumped them into took its language
from the path, which by then was the bare tool name with no extension, so an undefined
language was stringified into the fence itself.

The three now render as what they are: the file they act on, and the script, pattern or
program they run on it, with -i shown when the run rewrites the file rather than
printing it. The fence fix is general — every tool that names no file hit it.

Tests

Five new tests across the two fixes, each watched failing before the fix went in:
the capability merge carries the registry, a sed run is refused without a shared
registry and applies with one, and the four rendering cases.