Handle orphaned backup cleanup on safeWriteText failure #2409

Summary

Decide and implement how safeWriteText reports an orphaned backup when a write fails and backup cleanup also fails.

In src/services/file-safety/safeWriteText.ts, after a backup copy has been created, the failure handler makes one fs.unlink(backupPath) attempt and ignores its error. If the unlink fails, the previous content can remain on disk without the backup path being reported to the caller. By contrast, the successful publication path retries backup removal twice and reports a remaining backup with OrphanedPublishedBackupError.

A concrete trigger is a non-Windows parent-directory fsync failure after publication with backup: true, followed by a backup unlink failure. The caller receives PostCommitDurabilityError, but cannot locate the remaining backup from that error.

Proposed follow-up

• Decide the caller-visible error contract for a write failure combined with backup cleanup failure. Preserve the original failure information and distinguish whether publication succeeded.
• Align failure-path cleanup with the two-attempt backup cleanup behavior, and report any remaining backup path and cleanup failure to the caller.
• Retain the existing original-error behavior when cleanup succeeds, including when the backup is already absent.
• Add focused tests for a transient unlink failure followed by success, persistent cleanup failure, and preservation of the original write error and publication status.

The PR author reports that a test on PR #1914 at commit 28129e1544559e1f154b5a62d3c14e6757f40d31 uses platform: "linux" to pin the current one-attempt behavior after a post-commit directory fsync failure. The author also reports that changing the expectation to two unlink attempts fails. These are reported results, not a fresh test run.

References

• PR under review: feat(file-safety): serialized publish primitive over the shared file lock (split 1 of #1914, #1375) #2383
• Review comment: feat(file-safety): serialized publish primitive over the shared file lock (split 1 of #1914, #1375) #2383 (comment)
• Related PR and reported test: feat(tools): guarded write core under the shared lock (U5, #1375) #1914
• Requested by: @easonLiangWorldedtech