fix(windows): grant icacls by SID, not unqualified username

[asizux2]

Fixes #2478.

The bug

restrictFilePermissions() / restrictDirectoryPermissions() pass an unqualified username to icacls:

const user = os.userInfo().username;
execFileSync('icacls', [dirPath, '/inheritance:r', '/grant:r', `${user}:(OI)(CI)(F)`], { stdio: 'ignore' });

On a machine whose hostname equals the username, the bare name does not resolve to the user account. icacls writes an ACE for the machine SID instead, and because the same call passes /inheritance:r, the directory is left with a single ACE that matches nobody. The process that just created the directory can no longer enumerate or write to it.

Observed on Windows 11, hostname ESLAM, user ESLAM\eslam:

Form	Resolves to
eslam (current behaviour)	NTAccount.Translate throws "Some or all identity references could not be translated"
ESLAM\eslam	S-1-5-21-<redacted>-1001
whoami /user	S-1-5-21-<redacted>-1001

Net effect: browse can never start on an affected machine. mkdirSecure() creates .gstack/, hardens it into inaccessibility, and the daemon's next act is writing a lockfile inside. acquireServerLock() returns null on the resulting EACCES, so the user sees:

[browse] Another instance is starting the server, waiting...
[browse] Timed out waiting for another instance to start the server

which points at a concurrency problem that does not exist. icacls reports success and stdio: 'ignore' discards its output, so nothing surfaces the real cause.

The fix

Resolve the current user's SID and hand icacls the literal *<SID> form, which is immune to name-resolution ambiguity. Fall back to the domain-qualified name if the lookup fails.

One subtlety worth flagging for review: the SID lookup pins %SystemRoot%\System32\whoami.exe rather than calling a bare whoami. Under a bash-flavoured PATH (Git Bash / MSYS, extremely common for this tool on Windows) a bare whoami resolves to the MSYS build, which rejects /user. I hit exactly that on the first test run: the lookup silently failed and the code fell through to the qualified-name fallback. The fallback is correct, but without the pin the primary path would almost never fire.

Tests

The existing Windows cases only assert not.toThrow(), which this bug sails straight past, since icacls genuinely succeeds while writing a useless ACE. The added cases assert the contract that actually broke: the directory stays usable by the calling process after hardening. No icacls output parsing, so no locale or version brittleness.

Verified both directions on an affected machine:

Code path	Result
With this fix	15 pass, 0 fail
Pre-fix principal	7 pass, 8 fail

Several of those 8 are pre-existing tests (appendSecureFile, writeSecureFile). The suite could always have caught this; it just never ran anywhere the hostname matched the username.

Risk

Behaviour is unchanged on POSIX (the chmod paths are untouched) and unchanged on Windows machines where the bare username already resolved correctly, since *<SID> and the resolved name name the same principal. The fallback preserves today's behaviour if whoami.exe is unavailable.

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here