Recognize the Installer's Own Partial CLAUDE.md Rather Than Backing It Up as a Hand Edit #2454

What happens

When the installer leaves CLAUDE.md holding bytes it wrote itself, the next run reads that file as a hand edit. It backs the file up as "the edited prior file", and --report says the file "was edited since the last install". Nothing in that backup was written by hand.

Two states reach this:

• A write cut short. The installer truncates CLAUDE.md, the write fails partway, and the prior render cannot be put back. The partial file's digest matches no stamp, so the re-run that the failure message asks for backs it up.
• A freshly created file. write_regular_file opens with O_CREAT, so where fstat or the first ftruncate fails on a file that did not exist, an empty file is left behind. The next run backs that empty file up the same way. No practical trigger is known for this one.

The first predates #2426's change. Before it, a failed write_bytes left the same state. #2426 names the failure correctly now, which points the user straight at the run that mislabels it.

Shape that reproduces it

1. Install into a throwaway CLAUDE_HOME, so CLAUDE.md is an earlier render matching the stamp.
2. Change the render by adding text to the host-local file.
3. Re-run under a 4 KiB file-size limit. The run reports the file as left incomplete.
4. Run --report, then re-run without the limit. The report calls the file hand-edited, and the re-run writes a .bak of the truncated bytes.

Shape of a fix

Record the partial state rather than inferring it. For example, the installer could stamp the digest of what it actually left on disk when a write is cut short, so the next run recognizes its own output. Or it could remove a file it created itself when the write fails.

Found by the local strict review of #2426's fix branch. No content is lost, since the prior content was a reproducible render. The harm is a false statement and a backup that holds nothing worth keeping.