fix(mcp): restrict daemon state files to the owning user

[StefanSteiner]

What

The daemon state directory (~/.hyperdb, or HYPERDB_STATE_DIR) and the files in it took their permissions from the process umask — commonly leaving the directory at 0755 and daemon.json at 0644. daemon.json records the hyperd endpoint, and logs/ records it too, so both are now restricted to the owning user: 0700 for the directories, 0600 for the discovery file and for the files already inside.

How

A new daemon::state_perms module is the single place that decides how state paths are created, so the policy is not scattered across the three call sites that create them (discovery::write_discovery_record, daemon::run, and the main.rs daemon-mode log setup).

• The mode is set before any content is written. write_owner_only_atomic opens the temp file with OpenOptions::mode(0o600) and restricts the open descriptor as well, so the endpoint is never on disk in a world-readable file — not even briefly.
• The temp file is one this call made. It is unlinked and recreated with O_CREAT | O_EXCL and O_NOFOLLOW rather than opened with a plain create, which would open whatever already bore the name and leave the intended mode dependent on what that turned out to be. The record therefore always lands on a regular file inside the state directory, with the mode it is meant to have; a temp file left behind by an interrupted earlier write no longer carries its own mode into the record. Restricting the descriptor still matters, because OpenOptions::mode is a request the umask can narrow and a mode-less filesystem can ignore.
• The existing atomic-rename contract is preserved. The temp file is still renamed onto daemon.json, so a concurrent discover() sees either the old record or the new one. Because rename replaces the target's inode rather than rewriting it, the published file carries 0600 even when the target already existed with looser permissions — that is what corrects a record left behind by an earlier release.
• logs/ is restricted as a directory, and the files already in it are tightened too. hyperd is a separate process writing its own diagnostic logs there under its own umask, so the mode of a log it rotates next is not ours to choose; a 0700 directory settles the path for every file inside, whoever wrote it. But closing the directory says nothing about a log file already present, or about anything already holding one open, which is the state an upgrade actually meets — so regular files directly inside are corrected as well. The sweep is one level deep and skips anything that is not a regular file, so it cannot follow a link out of the directory or descend into whatever HYPERDB_STATE_DIR names.
• Directories left loose by an earlier run are corrected, not accepted as-is, at both levels — the state directory and the logs/ directory inside it.

Failure behaviour

chmod is refused outright on a filesystem whose permissions come from mount options rather than from each file — an SMB or NFS mount, exFAT or vfat, some container bind-mounts. That is not a statement about this directory's contents, and refusing to start there would trade a pre-existing condition for a total loss of the MCP on those setups: worse than what it was trying to fix, for a local developer tool. So tightening an existing directory warns and carries on.

The same filesystem refuses the call on the file as well, so simply propagating that refusal would leave the daemon warning about the directory and then unable to publish daemon.json at all — the same total loss, reached one step later. Instead the refusal is reconciled against the mode actually on disk:

• if the file already reads back with nothing granted to group or other, the record is protected — the filesystem is reporting a fixed mode — and it is published;
• if it reads back wider, nothing has protected the record, the error stands, and it is not published.

So "never publish a record whose permissions could not be set" is kept as an invariant about the mode that is really in force, rather than about whether a syscall succeeded.

Platforms

Unix modes have no Windows equivalent, so the mode calls compile out there. Windows relies on ACL inheritance instead: the default state directory sits under %USERPROFILE%, whose ACL grants the owning user, SYSTEM, and administrators — and not other interactive users — and a new subdirectory inherits it.

That inheritance is positional, so two things can move the state directory out of the profile, and they are not equivalent:

• Setting HYPERDB_STATE_DIR is the user's own call — now documented as such beside the variable in README.md and DEVELOPMENT.md, rather than only in a source comment.
• Inheriting a HOME from an MSYS2, Cygwin or Git Bash shell is not a choice about this directory at all. state_dir's documentation already described ~ as "HOME on Unix, USERPROFILE on Windows", but home_dir() tried HOME first on every platform — so under those shells the state directory landed outside the profile without the user having asked. Windows now prefers USERPROFILE and keeps HOME as a last resort, matching paths::persistent_home_dir. Unix resolution is unchanged.

No new dependency was added; the Unix path needs only std and the libc the crate already takes on Unix targets.

Tests

Unix-gated and assert the mode actually on disk (metadata().permissions().mode() & 0o777), not that a chmod was attempted — only the former is what another local account sees. Coverage: fresh directory and file; a pre-existing world-readable directory; a pre-existing world-readable directory tree (the shape an upgrade actually meets); pre-existing group- and world-readable files inside a loose directory; a rewritten world-readable file; a world-readable leftover temp file; a temp path that already resolves elsewhere; and both sides of the refused-chmod branch. One test drives the real write_discovery_file production path end to end through the existing isolated-child-process harness, and also asserts the record still round-trips — tightening permissions is worthless if it breaks discovery.

restrict_open_state_file takes the mode-setting call as a parameter so the refused-chmod branch is covered from both directions — published when the mode is already owner-only, not published when it is wider — without needing one of the exotic filesystems it exists for. Two guards pin the sweep's scope: it must not follow a link out of the directory, and it must not descend.

Before the change, the production-path test reported the real modes:

a newly created state directory was left at 0755 instead of 0700, so another local account can traverse it
a newly written discovery file was left at 0644 instead of 0600, so it is readable by other local accounts
a pre-existing world-readable state directory stayed at 0755 instead of being tightened to 0700
a pre-existing world-readable discovery file stayed at 0644 instead of being tightened to 0600

Gate

cargo fmt --all -- --check, cargo clippy --workspace --all-targets --all-features -- -D warnings, and RUSTDOCFLAGS="-D warnings" cargo doc --no-deps all clean; cargo test -p hyperdb-mcp 658 passed / 0 failed; cargo test -p hyperdb-api 632 passed / 0 failed; npx markdownlint-cli2 0 issues in 68 files.

Windows ACL behaviour and the USERPROFILE precedence were not verified locally (no Windows runner available) — the test (windows-latest) CI leg covers that the change compiles and the cross-platform tests pass there.

Note on overlap

Rebased onto upstream/main at 6cfe312, cleanly and with no conflicts, so this now sits on top of #290 and #292.