fix: restrict ~/.openwiki ACLs on Windows where chmod is a no-op

[Wenyu Chiou (WenyuChiou)]

What

Adds restrictDirToCurrentUser (src/windows-acl.ts) and wires it into the two places that express the home directory's 0o700 owner-only intent — ensureOpenWikiHome and saveOpenWikiEnv:

• On win32, runs icacls <dir> /grant:r <user>:(OI)(CI)F *S-1-5-18:(OI)(CI)F, then icacls <dir> /inheritance:r — full control for the current user and SYSTEM (well-known SID, language-independent), inheritable so newly created children (.env, openwiki.sqlite, connectors/**) are covered, inherited ACEs removed.
• Fail-safe ordering: the grant runs before the inheritance reset, so a failed grant can never lock the user out of the directory.
• Best-effort by design: returns false instead of throwing (mirroring the surrounding chmodIfExists semantics) — a machine without working icacls never fails a run.
• No new dependencies; no-op on non-Windows platforms, so POSIX behavior is completely unchanged.

Why

On Windows, Node's fs.chmod only toggles the read-only attribute and the mode option on mkdir/writeFile is ignored — so the existing 0o700/0o600 calls protect nothing there, and ~/.openwiki (plaintext .env with every provider key and the ChatGPT refresh token, sqlite chat checkpoints, raw connector dumps) simply inherits its parent's ACL.

Verified on a real Windows 11 machine (machine name redacted). A fresh directory before/after the helper:

BEFORE (inherited from parent):
  ... a dozen inherited ACEs with (M) modify rights, including sandbox users ...
  NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
  BUILTIN\Administrators:(I)(OI)(CI)(F)
  MACHINE\user:(I)(OI)(CI)(F)

AFTER restrictDirToCurrentUser:
  NT AUTHORITY\SYSTEM:(OI)(CI)(F)
  MACHINE\user:(OI)(CI)(F)

Scope notes, stated explicitly: pre-existing files keep the ACEs they already inherited (no recursive /T pass — new children inherit the restricted ACL; a recursive apply on a large connectors/raw tree could be slow and is easy to add later if wanted). Administrators lose their inherited ACE on the directory but can still take ownership — the same way root bypasses 0o700 on POSIX.

How tested

• New test/windows-acl.test.ts (3 tests, mocked node:child_process, runs on any platform incl. ubuntu CI): non-win32 no-op; exact grant + inheritance-reset argument sequence with grant ordered first; grant failure short-circuits without removing inheritance (the lockout guard).
• Real-machine integration check on Windows 11: icacls output before/after shown above.
• pnpm run format, pnpm run lint, pnpm test: 298/300 pass locally on Windows; the 2 failures are the pre-existing win32 test/env-behavior.test.ts platform checks (they reproduce on pristine main) — notably, this PR is the change that makes the intent of those 0600 expectations real on Windows at the ACL layer.

Fixes #366

🤖 Generated with Claude Code