writing truncation log entry in case of truncation after failing a write

[hg-ms]

Log a truncation entry when rolling back a partial store.

When one channel's write fails mid-store while a sibling channel already wrote its slice, the engine rolls back the successful channel by truncating its data file. Previously StorageFileManager.rollbackWrite truncated
the file but never recorded a matching truncation entry in the transaction log — so the store entry written earlier kept claiming the larger, pre-rollback length. On the next start, validateStorageDataFilesLength saw
a data file shorter than its logged length and threw StorageExceptionConsistency, leaving the storage permanently un-openable.

The fix makes rollbackWrite write a FILE_TRUNCATION transaction entry before truncating (mirroring handleLastFile), keeping the transaction log and the data file consistent. A totalLength() != size() guard ensures
only channels that actually wrote uncommitted data emit an entry. On restart, the recovery analysis resolves the store-then-truncate pair to the rolled-back length and reopens cleanly to the last consistent state —
the truncation case the transaction analysis was already designed to handle.

[Copilot]

Pull request overview

This PR fixes a recovery/consistency issue where a partial store rollback truncated a data file without writing a corresponding FILE_TRUNCATION transaction entry, allowing the transaction log to claim a larger length than the actual file and potentially preventing storage from reopening after restart.

Changes:

• Add a guard in rollbackWrite() to only emit truncation behavior when needed.
• Write a FILE_TRUNCATION transaction entry before truncating during rollback, mirroring handleLastFile() behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[hg-ms]

fixed #704