Review follow-up on #8052. A batched LSP write recorded only the
destination, and the flush reread each entry from disk before
post-processing. That reread tolerated `ENOENT` and rethrew everything
else, so a destination a sandbox denies for reading as well as writing
failed the flush after every write in the batch had already succeeded,
the brokered one included. The tool call owning the flush then reported
failure for bytes that were on disk, contradicting the seam's promise
that a native tool continues as if its own write had worked.
The pending entry now carries the content it committed. The flush still
prefers a fresh read, so an external change made before the flush wins
and a file deleted before it is still not recreated; the remembered
bytes stand in only when the read is denied. Recovered content flows
into `runLspWritethrough`, whose `writeContent` already routes through
`writeFileWithFallback`, so a formatter rewrite of it is brokered too.
This also fixes a shape that predates the seam: a plain write-only file
(mode `0o200`) failed the same flush with nothing registered at all.
Covered by a real-permission test in `test/tools/lsp-batching.test.ts`
that brokers a write to a `0o000` file inside a batch and then flushes;
rethrowing instead of substituting the remembered bytes fails it with
`EACCES` from `flushWritethroughBatch`.
Larry Gordon
2230361fcd