Propagate ENOENT from safeWriteText backup creation #2389

Summary

safeWriteText can publish without the requested backup when backup creation fails with ENOENT. Track the behavior change as a separate unit.

In src/services/file-safety/safeWriteText.ts, the catch around the backup step handles ENOENT from both fs.access(targetPath) and later operations. For example, if the backup disappears after copyFile, chmod can raise ENOENT; the current code swallows the error and continues to publish.

Proposed change

Handle a missing target at the target access check. Propagate ENOENT from backup creation operations after successful access instead of treating it as a missing target. Preserve the ownership rule: do not remove a backup path that this write did not create. Preserve reporting of an owned backup that cannot be cleaned up.

Acceptance criteria

• With backup: true, a missing target at the access check still permits a new file to be published without a backup.
• After successful target access, injected ENOENT from backup creation, including copyFile or chmod, rejects the write and does not publish. Verify cleanup and that the previous target content remains unchanged.
• Cleanup does not delete a backup path owned by another writer; an owned partial backup that cannot be removed is reported.
• Add focused regression tests in src/services/file-safety/__tests__/safeWriteText.spec.ts. The failure-path tests describe the proposed behavior and are expected to fail before the fix.

Requested by @easonLiangWorldedtech.

PR: #2385
Review thread: #2385 (comment)