The biometric enrollment marker has its own temp-plus-rename writer and misses every guarantee write_private makes

[Sadykhzadeh]

vault_keychain_cleanup.rs writes the biometric enrollment marker with its own temp-plus-rename helper instead of going through fs_util::write_private, so none of what write_private guarantees applies to it. #45 called this "adjacent, not part of this" and #46 left it alone; now that #46 has landed the Windows half, the two implementations have visibly diverged.

write_marker:

let mut options = std::fs::OpenOptions::new();
options.write(true).create(true).truncate(true);
#[cfg(unix)]
{
    use std::os::unix::fs::OpenOptionsExt;
    options.mode(0o600);
}

let mut file = options.open(&tmp)?;

Three differences from write_private as it now stands:

• No restriction on Windows. The mode(0o600) is cfg(unix) and nothing takes its place, so the marker takes whatever %APPDATA% hands down — the state fs_util.rs was in before Give Windows state files an explicit owner-only DACL instead of the profile's inherited one #46.
• CREATE_ALWAYS, not CREATE_NEW. A file already sitting at biometric_enrollment.json.tmp is written through rather than refused, so the file object that ends up under the marker's name can be one another process placed there. On Windows that object carries its owner across the rename, and the owner outranks the DACL. Give Windows state files an explicit owner-only DACL instead of the profile's inherited one #46 fixed exactly this in write_private.
• No fail-closed posture. There is nothing to fail closed on, since there is no restriction to attempt.

The marker holds a keychain binding id and a scope token rather than key material, so this is not a disclosure on the scale of vault.json. It is a second implementation of an operation the codebase has already decided how to do, sitting in the same directory as the files that get the careful treatment, and it will keep drifting.

Suggested fix: route the marker through fs_util::write_private. That needs write_private (and a matching read) exposed from clavyn-core rather than pub(crate), which is the only real design question here — desktop is the caller and the marker is desktop-only state. The alternative, duplicating the Windows DACL and owner work in vault_keychain_cleanup.rs, is the outcome worth avoiding.

Not urgent, and deliberately out of scope for #46, which stayed inside core/src/fs_util.rs.