Bound leaked ActiveEnumeration collection behind an off-by-default flag + Heartbeat observation telemetry

[tyrielv]

Background

GVFS.Mount crashes surface downstream as STATUS_FILE_SYSTEM_VIRTUALIZATION_UNAVAILABLE (0xC000CE01): once the mount dies, the ProjFS virtualization root is orphaned and every subsequent placeholder access fails. Watson attributes the crashes to radar_high_memory projectedfslib.dll!prjcompletecommand — GVFS.Mount is crashing under memory pressure in the native ProjFS command-completion path.

One suspected managed-side contributor: ProjFS does not always deliver EndDirectoryEnumeration for a StartDirectoryEnumeration (e.g. cancelled enumerations), leaking the ActiveEnumeration — and the projected item list it pins — in activeEnumerations. Over a long-lived mount this grows without bound.

We do not yet have direct evidence that this leak is a dominant driver of the memory pressure. So this PR is deliberately structured to measure first, act second:

What this PR does

1. Observation telemetry — always on.

• ActiveEnumeration tracks a monotonic LastActivityTickCount.
• New FileSystemVirtualizer.AddHeartbeatMetadata hook; the Windows virtualizer reports ActiveEnumerationCount / ActiveCommandCount on the periodic Heartbeat event, regardless of the flag below.
• This ships the signal needed to confirm/refute the leak on real machines.

2. Eviction — off by default, behind gvfs.max-active-enumerations.

• Unset or <= 0 → eviction disabled, enumeration hot path unchanged (the default).
• > 0 → a throttled sweep (≤ once/min, only once the collection exceeds the configured count) evicts enumerations idle longer than 5 minutes.
• Monotonic clocks for both the throttle and the staleness cutoff; the throttle claim uses Interlocked.CompareExchange keyed on the previously-read tick so two threads in the same interval can't both sweep.

Evicting a live-but-idle enumeration is safe and loud: the next GetDirectoryEnumeration for that id misses the collection and returns HResult.InternalError (fails that one listing rather than returning truncated results as if complete), and every eviction is traced.

Relationship to #2042 (independent — either order)

#2042 addresses a different lever on the same crash: it stops a single failed native ProjFS call from taking down the whole mount (survive-and-report instead of crash). This PR instead targets the memory pressure that triggers those faults, and gates the behavior change off until telemetry justifies it.

The two are independent: this branch does not contain #2042's commit and references none of its code (and vice-versa). They can be reviewed and merged in either order with no rebase — verified with git merge-tree (clean, no conflicts). #2042's own investigation (a local repro that showed enumeration cancellation self-heals and is not the OOM driver) is part of why the eviction here is unproven and therefore gated off by default.

Open questions this is meant to answer

1. Does activeEnumerations actually grow without bound in the field? (Heartbeat ActiveEnumerationCount.)
2. If so, does bounding it measurably reduce the native-ProjFS-under-memory-pressure crash rate? (Enable the flag on a ring and compare.)

Testing

• ActiveEnumeration records activity time.
• Heartbeat metadata reports the live enumeration count.
• Eviction disabled → stale enumerations retained.
• Eviction enabled → stale enumerations evicted (subsequent End → InternalError), freshly-active ones kept.
• Full unit suite passes (881 passed, 0 failed, 11 skipped).