Report orphaned staging links after no-replace publication #2390

Summary

In src/services/file-safety/safeWriteText.ts, a successful failIfExist commit publishes the target with a hard link. If unlinking the staging path fails, the function suppresses the error and returns success. The staging path remains a second link to the published file, and an owned staging directory can remain on disk.

For a caller-supplied tempPath, reusing and truncating that path can also truncate the published target. Later in-place edits through either link affect the same file.

Required change

Retry cleanup of the staging link after publication. If cleanup still fails, report the staging path and the fact that the target was already published. Preserve the published target and avoid treating the write as uncommitted. Choose and document a caller-visible reporting mechanism that accounts for the post-commit state, such as a warning or a distinct partial-failure error. Respect staging-path ownership and do not unlink a path that has been reused by another operation.

Acceptance criteria

• A transient unlink failure is retried and the staging link is removed when the retry succeeds.
• A persistent unlink failure is observable and identifies the published target and remaining staging path.
• The published target is preserved, and callers can distinguish publication from an uncommitted write.
• Tests cover both an internally created staging file and a caller-supplied tempPath, including the risk from reusing the remaining hard link.
• Tests cover cleanup of the owned staging directory and verify that cleanup does not remove a reused staging path.

Context

This follow-up is outside the six-unit plan on #2350, as reported by the requester. PR #2385 reports 448 counted executable lines against a 500-line limit, so the requester asked to keep this work in a separate unit.

Requested by @easonLiangWorldedtech.

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