perf(state_manager): [DSM-145] Flush large writes from background syncfs thread

[alin-at-dfinity]

The blocking syncfs in finalize_and_remove_unverified_marker flushes the dirty data produced earlier in the checkpoint (notably the freshly serialized per-canister protos). At high canister counts this is ~15s on the CUP-critical path. Previously it was cheap only because the overlay/Wasm validation (being removed in #10776) happened to give background writeback time to drain that data first.

Spawn a dedicated TipSyncfs thread that the tip thread pings (non-blocking, bounded(1) + try_send, self-coalescing) after every large batch of file writes/hardlinks: after serializing Wasm binaries and protos, after flushing a round's page-map deltas, and after reset_tip's hardlink tree and the merge. The kernel then flushes that data concurrently with the rest of the checkpoint, so the blocking syncfs in finalize finds little left to do (~15s -> ~0.1s at 200k canisters).

finalize's syncfs stays as the durability barrier, so the background syncfs calls are purely an optimization and their errors are non-fatal.

[zeropath-ai]

✅ No security or compliance issues detected. Reviewed everything up to 0961b3b.

Security Overview

• 🔎 Scanned files: 2 changed file(s)
• 🔗 Scan Link: https://zeropath.com/app/repositories/f5e9d2bb-29a4-4b64-902a-391d65fd8b2d?scanId=f520ae89-4ec3-42e3-a324-724a1ca5e1f0&codeScanTypes=PrScan&tab=issues

Detected Code Changes

Change Type	Relevant files
Enhancement	► rs/state_layout/src/state_layout.rs     Add syncfs method on StateLayout and internal syncfs helper supporting Linux and fallback to sync_all on non-Linux platforms ► rs/state_manager/src/tip.rs     Spawn background TipSyncfs thread to perform non-fatal background syncfs calls after writes     Trigger background syncfs on various tip operations to flush filesystem changes earlier