Start config persistence groundwork with checked startup saves

[Guffawaffle]

Config::Load already writes a default config when missing and a runtime snapshot at startup. This checks those existing writes: serialize and parse before touching disk, stage privately, check writes and close, then replace the destination while preserving existing permissions. Save failures are logged and startup continues with the in-memory configuration. Existing and dangling final symlinks retain their routing.

No additional save cycle is introduced. This is the whole-document startup writer; comment-preserving runtime edits remain in #280. Refreshed onto current dev, preserving #313's independent hook switches. Supersedes #278.

Validation: Windows release build; existing creation, ACL, sharing, short-write and failed-close fixtures, including staging ACL checks before/during writes and after close; all 11 example TOMLs. macOS mode and dangling-link fixtures run in the existing Intel/ARM CI jobs. Native macOS execution and Windows partial-replacement recovery fault injection remain outstanding; power-loss durability is not claimed.

[netniV]

I'm not sure what this for, it seems to add the overhead of saving the configuration file which we never do.

[Guffawaffle]

Fair question—the existing writer is adequate for the limited startup use, and this PR's immediate benefit there is modest. Config::Load already creates the config when it is missing and writes the generated runtime snapshot; this doesn't add new save triggers or background work.

I split this out as a small, separately reviewable first step for #280, which supplies persistence for the in-game settings work. Before repeatedly editing the player's actual config, I wanted a checked file-writing foundation: detect write/close failures and stage the new contents before replacing the existing file, rather than truncating it first and potentially leaving a partial file without reporting the failure. The platform-specific handling is there to preserve permissions and deal with replacement failures.

#280 adds the formatting/comment-preserving edits and runtime save coordination separately. I'm happy to trim anything here that isn't pulling its weight; the checked write-and-replace behavior is the part I think is worth establishing before building runtime saves on it. I should have made that split clearer in the PR description.

[Guffawaffle]

Hook/feature alignment follow-up for #313

Follow-up to #313: keep hook installation independent of feature enablement, with default-enabled compatibility switches under [patches] and feature checks inside the installed hooks.

No direct feature-gated installer mismatch was identified in this startup-save change. This comment tracks the persistence parent in the settings cascade: preserve #313's current configuration/patch-switch parsing when updating this branch, then propagate the refreshed parent through #280 and the dependent settings branches. Do not add unrelated hook changes to this PR.

Settings cascade (verified from current branch ancestry): #279 → #280; #277 + #280 → #281 → #282; sibling branches from #282 are #285, #293 and #297. #285 additionally depends on #269; #297 additionally depends on #296. Correct the owning parent first, then carry the fix through every dependent branch while preserving each sibling's scope.

Implemented in 25d78b535335ea1a83863d4220c2cb19ec4152db. Current upstream hook-switch parsing is preserved. Reviewed corrections also protect temporary configuration contents at creation and preserve dangling final symlinks. Windows build and existing fixtures passed. CI has started for this head; propagation to #280 and its dependent settings branches follows. Native macOS execution and Windows partial-replacement fault injection remain outstanding.