fix(data): reject destructive JSON store shrink

[mikemikimike]

Related issue

Related to #1458

Background

A whole-file JSON store can be overwritten by a stale or partial in-memory view. The existing shrink check preserved a .prev copy but still replaced the live store, so the running instance could immediately lose the data it needed.

Changes

• Reject destructive JSON store shrinks instead of replacing the live file.
• Fail closed when the recovery copy cannot be read or written.
• Serialize the shrink-check, recovery-copy, and live-file replacement sequence within the process.
• Extend regression coverage for failed recovery copies and preserved live contents.

Compatibility

Normal writes and legitimate changes below the shrink threshold are unchanged. Callers that attempt an unexpectedly destructive JSON write now receive an error and must repair or explicitly handle the operation.

The mutex protects concurrent writers in one process. Cross-process writers and equal-sized stale snapshots would require a file-lock or versioned compare-and-swap protocol and are outside this focused change.

Verification

• GOPROXY=https://goproxy.cn,direct go test ./internal/data -run 'TestAWriteThatLosesMostOfAStoreKeepsACopy|TestSaveJSONRejectsShrinkWhenPreviousCopyCannotBeWritten|TestSaveJSONPreservesPreviousContentsOnMarshalFailure|TestSaveJSONRoundTripLeavesNoTempFiles' -count=1 — passed.
• gofmt -w internal/data/data.go internal/data/atomic_test.go — passed.
• git diff --check — passed.
• GOPROXY=https://goproxy.cn,direct go test ./internal/data -count=1 — not green on Windows because existing tests expect Unix file modes (0600) and SQLite cleanup encounters a locked file.
• GOPROXY=https://goproxy.cn,direct go test ./... — not green on Windows due existing platform-specific syscall.Statfs_t/syscall.Statfs build errors, file-lock failures, permission-mode failures, and proxy environment assumptions.

No Docker service is required for this unit-level change.