fix(backup): classify temp write failures correctly

[efegokdemir]

Summary

• distinguish backup temp-file write failures from genuine source-read failures
• share the existing ReadTo writer-tracking/classification logic between backup and restore
• keep temp-file write failures fatal instead of counting them as skipped source files
• preserve existing source-read skip behaviour
• use one shared injectable temp-file factory while keeping backup and restore filename patterns distinct
• preserve existing restore behaviour

Regression coverage

• temp file creation succeeds
• the temp file is then reopened read-only
• the real storage ReadTo fails while writing to that destination
• the resulting backup error is not classified as a source-read error
• SkippedFiles remains zero
• existing restore-side destination/source classification coverage remains intact

Validation

• go test ./internal/backup/...
• go test -race ./internal/backup/...
• go vet ./internal/backup/...
• go test ./...
• go build ./...
• git diff --check

All pass locally.

Closes #779

[xe-nvdk]

Approving. This is the lift-and-share #779 asked for, done without changing either side's error wording.

• trackingWriter, the temp-file seam, and the classifier now live in readto.go with one shared createTempFile(pattern), so backup and restore keep distinct temp-file names while sharing the test seam. classifyReadTo stays as restore's thin wrapper, so nothing that matches on its messages moves.
• streamBackupFile wraps the temp file and classifies with errBackupRead, so isSourceReadError keeps working for genuine source reads and a temp-side failure is fatal. The new test drives it the same way the restore test does (read-only temp file), asserts the error is not a source read, and asserts SkippedFiles stays zero.
• Verified on your head: go build ./cmd/... ./internal/..., gofmt and vet clean, the backup suite twice under -race, both seam tests green, and no reference to the old createRestoreTemp remains. CI green.

One thing I did on your branch: main moved after your base, so the note conflicted positionally. I merged main into fix/backup-temp-write-classification (1343ef6, a merge commit, no rewrite), kept your entry on top, verified the merged tree, and pushed. Pull before pushing again.

Two notes, neither blocking:

1. The paragraph on streamBackupFile that stated its classification contract ("only a source-read failure is wrapped with errBackupRead; temp file, seek and write failures are fatal") was deleted rather than updated. It was the one place that said the rule out loud. Please restore it with the tracking-writer clause added, the way streamRestoreFile's comment reads.
2. Wrapping the temp file costs the source→temp hop its zero-copy fast path on Linux, exactly as it did on restore in #778. On restore that is a rare, disk-bound operation. On backup it runs on a schedule, so the cost is worth stating in the release note, and I have filed a separate follow-up to get zero-copy back while keeping the attribution. Nothing for this PR beyond the sentence.

Thank you — three for three today.

[xe-nvdk]

Merging — thank you @efegokdemir. Six of yours in across two days. README credit follows in a moment; #791 (the zero-copy follow-up) is yours if you want it.