perf(review): Windows owner creation repeats SID identity probes #2074

Before submitting

• I searched open and closed issues and did not find a report of this problem.
• I reviewed this report and removed credentials, tokens, private paths, hostnames, and other sensitive data.

The contributing coding agent performed these duplicate and privacy checks with explicit user authorization; these attestations describe agent actions, not personal facts about the user.

Problem

On Windows, one module-controlled synchronous createCandidateOwner operation acquires the same user/local-administrator SID identity twice: once for parent-boundary validation and again for the new owner marker's private-file validation. The identity subprocesses add avoidable latency even though the parent and marker checks belong to the same synchronous creation.

A bounded direct Windows sample with two creations per side measured mean creation time of 986.2ms baseline versus 817.9ms candidate (~17.1%). User SID and administrator SID probes each decreased 2 to 1 per creation; filesystem owner and DACL observations remained 4 each. This small sample is illustrative, not a general latency guarantee.

This is distinct from #990 and #1446 (probe timeouts), #1023 (trusted-helper resolution), #775 (Windows permission validation) and #1809 (identity-precision fixture failure). The proposed identity lifetime remains restricted to creation; preparation already acquires identity once and is unchanged.

Steps to reproduce

1. On Windows with Node v24.14.0, check out baseline source commit 2d7ab4ba3ad09b652d0fa1de56842e02b5db4669.
2. Create an isolated temporary common-directory fixture with the existing gentle-ai/candidate-views hierarchy, then call prepareCandidateOwnerParent(commonDir, "win32") to enforce the existing privacy boundary.
3. Instrument subprocess counts without changing their results. Call createCandidateOwner(commonDir, join(parent, randomUUID()), "win32") for a fresh UUID and record elapsed time plus user SID, administrator SID, owner and DACL probes.
4. Observe two acquisitions of each identity category during one creation. Repeat with a fresh UUID to confirm each operation acquires its own identity.
5. Compare with the preserved candidate implementation in commit 1efccb5a01445d84ca554e0dea9f733362c4a8c8: one fresh identity acquisition per creation, with the same independent owner/DACL observations.

Use isolated fixtures and remove only files owned by the fixture. The candidate was removed from PR #2068 to keep that PR scoped to the separate subagent Git-cache issue.

Expected and actual behavior

Expected: acquire Windows user/administrator identity once within one module-controlled synchronous owner creation, reuse only that identity through creation-local validation/rollback, and reacquire identity on the next operation.

Actual: identity is acquired again for the marker validation during the same creation.

Safety constraints: do not cache filesystem owner or DACL facts, add a process-wide SID cache, weaken private-owner checks, change public signatures, or pass retained identity into callback-based cleanup/sweeping. Preparation already acquires once and must remain unchanged. Identity failures must fail closed, and rollback must preserve a marker whose current owner cannot be re-proven.

The preserved candidate's focused checks passed 12/12 with no skips, typecheck reported zero diagnostics, and independent security verification passed. These do not claim the entire local suite passed; the full suite was incomplete, and unrelated fixture/catalog failures remain separate.

gentle-pi version

From source: baseline 2d7ab4ba3ad09b652d0fa1de56842e02b5db4669; preserved candidate 1efccb5a01445d84ca554e0dea9f733362c4a8c8.

Pi version

1.1.0

Operating system

Windows

Relevant logs or error output (optional)

Bounded direct sample, two creations per side:
baseline mean: 986.2ms
candidate mean: 817.9ms
user SID probes per creation: 2 -> 1
administrator SID probes per creation: 2 -> 1
owner observations per creation: 4 -> 4
DACL observations per creation: 4 -> 4
focused identity/owner checks: 12/12, no skips