ProjFS: only tolerate FilterAttach ACCESS_DENIED for unelevated callers

[tyrielv]

Summary

Narrows the ACCESS_DENIED tolerance added in #1980 so it only applies to unelevated callers of ProjFSFilter.TryAttachToVolume. This keeps the unelevated gvfs mount fix intact while ensuring the elevated GVFS.Service no longer silently swallows a genuine attach failure.

Background

#1980 made TryAttachToVolume treat ACCESS_DENIED from FilterAttach as success whenever the ProjFS service is running. Both callers share this method:

• ProjFSFilter.IsReady() — runs in the (usually unelevated) gvfs mount process.
• EnableAndAttachProjFSHandler.Run() — runs in GVFS.Service, which is elevated (LocalSystem).

The problem (error-swallowing risk)

FilterAttach requires SE_LOAD_DRIVER_PRIVILEGE, checked as a privilege gate at the API entry point:

• An unelevated caller always gets ACCESS_DENIED, regardless of whether the filter is actually attached. When the service is running, the (elevated) service already attached the filter, so tolerating this is the correct fix — and is the whole point of ProjFS: tolerate ACCESS_DENIED on FilterAttach, remove dead bundled-driver code #1980.
• An elevated caller (the service) holds the privilege, so ACCESS_DENIED is never the benign case there. It signals a real problem — AV/EDR lock, Group Policy restriction, or driver corruption — and swallowing it lets the mount proceed in a broken state with no actionable error.

Before #1980, the service called raw TryAttach and reported that failure. After #1980 it swallows it. This PR restores that safety for the elevated path.

The fix

Add a !WindowsPlatform.IsElevatedImplementation() guard to the tolerance condition. ACCESS_DENIED is a deterministic privilege gate, not a transient contention error, so distinguishing purely on elevation is precise:

• Unelevated gvfs mount: still tolerated → ProjFS: tolerate ACCESS_DENIED on FilterAttach, remove dead bundled-driver code #1980 fix preserved.
• Elevated GVFS.Service: ACCESS_DENIED surfaces again → genuine failures are reported, not masked.

This also aligns the code with the existing comment's stated intent ("when the caller lacks this privilege"), which the merged code never actually checked.

Explicitly out of scope

A bounded retry loop for "transient AV-scan contention" is not included: FilterAttach's ACCESS_DENIED is a deterministic privilege gate, not a sharing/contention error (which would surface as a different HRESULT). Retrying would add latency and still mask real failures.

Tests

• GVFS.Platform.Windows, GVFS.Service, and GVFS.UnitTests build clean (0 warnings, 0 errors).
• ProjFSFilterTests — 3/3 passed.