Handle export metadata failures after exclusive file creation #54

Problem

In released v1.7.5 (ab53e31e57022b6e5f88e2ac3706d135938c48c8), exportReadPayload() opens a new destination with wx / requested mode 0600, then calls fstatSync(fd) before entering its cleanup try block. If that call throws, the newly created empty file can remain and the descriptor is not explicitly closed until process exit.

Source: read-views.mjs:108-123.

This is a source-inspected exceptional failure path, not a reproduced production incident. Existing destinations are not overwritten, no successful receipt is returned, and the failed output is not acknowledged. It was explicitly retained as a non-blocking limit in PR #53.

Follow-up after v1.7.5 usage

• Add a focused fault-injection regression for failure immediately after exclusive creation.
• Ensure descriptor cleanup covers metadata acquisition failures.
• Define safe handling of the new file when its identity could not be obtained. Never blindly unlink a pathname that may have been replaced; preserve the existing dev/inode ownership protection.
• Verify no receipt / result acknowledgement on this failure, plus existing-file and symlink refusal and replacement protection.
• If safe removal cannot be established, explicitly report/document retained-file behavior without exposing payloads or sensitive paths.

No new dependency or crash-durable/atomic-publication redesign is implied. Do not start implementation as part of the v1.7.5 release; revisit after real usage.