Harden orphan-lock detection against false-release on transient failures

[tyrielv]

Summary

Risk-reduction hardening for the orphan-lock detection change merged in #1989, ahead of the GVFS 2.0 stabilization release. #1989 was flagged 🔴 (highest "worse-regression-than-it-fixes" tier) because it is a concurrency fix; this PR removes the one dangerous failure mode it introduced while keeping the fix it delivered.

This does not reopen #1989 (already merged) — it is a focused follow-up off current master.

The regression being removed

#1989 captures the lock holder's process start time at acquire and compares it at each orphan check to distinguish the real holder from an unrelated process that recycled its PID. Correct for the recycle case — but it collapsed every failure to read the start time into a single bool false, which the caller treats as "holder is gone → release the lock."

The dangerous path is a transient OpenProcess(QUERY_LIMITED_INFORMATION) failure (e.g. momentary resource pressure) for a holder that is still alive: the merged code releases the lock, admitting a second writer to the index. That is a corruption-class failure — strictly worse than the flaky hang #1989 fixed.

Note the pre-#1989 code did not have this exposure: its liveness check fell back to Process.GetProcessById when OpenProcess failed. #1989 dropped that fallback on the identity path. This PR restores "never release without positive evidence" without reintroducing the identity-blind GetProcessById check (which would defeat #1989's recycle detection).

The change

TryGetActiveProcessStartTime now returns a ProcessStartTimeResult enum instead of bool:

Result	Windows mapping	Orphan-check action
Success (time == captured)	opened, still active, same creation time	Hold (same holder)
Success (time != captured)	opened, still active, different creation time	Release — PidRecycled (the #1989 case)
ProcessNotFound	ERROR_INVALID_PARAMETER, or opened-but-exited (exit ≠ STILL_ACTIVE)	Release — positive evidence gone
Inaccessible	ERROR_ACCESS_DENIED	Release — see gate argument
Indeterminate	any other error (ERROR_NOT_ENOUGH_MEMORY, ERROR_NO_SYSTEM_RESOURCES, …)	Hold + telemetry — we don't know, so we never false-release

The Win32 error is read via Marshal.GetLastWin32Error() (the P/Invokes are already SetLastError = true).

Why Inaccessible → Release is safe (acquire-time gate)

We only enter the identity-check path for a holder whose start time we successfully read at acquire — i.e. one this mount could OpenProcess. OpenProcess access is a stable function of the caller token and the target's protection level / DACL, and git/hooks never rewrite their own DACL. So a live original holder we could open before cannot later become inaccessible; an access-denied result means the PID now refers to a different process → releasing is correct. The pre-existing null-start-time fallback (when we couldn't read start time at acquire) is unchanged.

Blast radius

• In-memory, mount-side only. The captured start time is never serialized; the named-pipe lock protocol is unchanged → no cross-version / wire-format impact.
• The only behavioral change vs. Fix PID-recycling race in orphan-lock detection #1989 is: transient/unknown read failures now hold instead of release. Every case Fix PID-recycling race in orphan-lock detection #1989 released on positive evidence still releases.

Telemetry

The Indeterminate hold emits ExternalHolderLivenessIndeterminate (Verbose) so we can measure whether these transient failures ever occur in the field.

Tests

Adds unit coverage for the new outcomes and keeps the existing identity tests:

• WhenHolderProcessNotFound → released
• WhenHolderInaccessible → released (gated-recycle)
• WhenHolderIndeterminateKeepsLock → held (the anti-false-release guard)
• retained: WhenHolderPidRecycled, WhenHolderStartTimeMatches

Validation: dotnet build GVFS.UnitTests clean; full GVFS.UnitTests suite 885 passed, 0 failed (11 skipped by category); all 5 identity tests pass.

Assisted-by: Claude Opus 4.7