[Feature request] Checked preference commits before Companion shutdown #3719

The small fix in #3716 preserves dirty flags when a preference save fails. A separate hardening change in a SuperBase fork writes preferences to a temporary file and only renames it over the destination after successful serialization, flush and close. It also retries failed saves at a bounded interval and prepares preferences/pending contacts before shutdown, reboot or DFU; a failed preference save cancels the transition.

I would like agreement on the filesystem and board API boundaries before proposing this more extensive change to dev.

Questions for the upstream approach:

• Should the temporary-write/rename path be board-scoped initially, or common to Companion stores after verifying each supported filesystem's replacement semantics?
• Is a board shutdown-preparation callback appropriate, or should the existing power-management path own the save result?
• What retry/reporting behavior is preferred if serialization, flush, removal of an old temporary file, or rename fails?
• Contact serialization does not expose every failure today. The implementation should not imply that preferences and contacts form one atomic transaction.

The fork implementation has host fault-injection coverage for failed/partial preference writes and retry state. Device settings persisted across resets/updates in SuperBase tests. Physical power interruption during a flash write has not been exercised, and atomic replacement is not claimed for unverified filesystems. No identity, key or configuration export is required to test the failure paths.

If the approach is welcome, this can follow #3716 in an independent PR with backend-specific tests and explicit failure behavior.