[ci-scan] PhysicalFileProviderTests.TokenForEmptyFilter fails on tvOS device (Assert.False: Expected False, Actual True)

## Reasoning

`PhysicalFileProviderTests.TokenForEmptyFilter` failed with `Assert.False() Failure: Expected: False, Actual: True` on a physical tvOS device (`DNCENGTVOS-111`, tvOS 26.2) in the `runtime-extra-platforms` pipeline. The test creates a change token via `Watch("")` (empty filter) and expects the resulting token to not be active (have called back) initially. The failure means the token's `HasChanged` (or callback-triggered status) returned `True` when `False` was expected.

This failure did **not** appear on tvOS simulators or other platforms in the same build (1406427). It also did not appear in prior builds checked (1404759, 1403076, 1401195), suggesting this may be a new regression or intermittent device-specific issue on real tvOS hardware.

## Impact on platforms

- **tvos-arm64** (real device `DNCENGTVOS-111`, tvOS 26.2) / osx.15.amd64.appletv.open Helix queue / Mono full-AOT / exit code 1
- Build: 1406427 (2026-05-03T09:02:27Z)
- First (and only) confirmed occurrence in the scanned window

## Errors log

From Helix job `1a028d92-a44d-4600-9316-18cbc19457ea`, work item `Microsoft.Extensions.FileProviders.Physical.Tests` on tvOS device:

```
[FAIL] Microsoft.Extensions.FileProviders.PhysicalFileProviderTests.TokenForEmptyFilter
Assert.False() Failure
Expected: False
Actual: True
at Microsoft.Extensions.FileProviders.PhysicalFileProviderTests.TokenForEmptyFilter()
at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)
```

Test run summary: Tests run: 90 Passed: 80 Inconclusive: 0 Failed: 1 Ignored: 0 Skipped: 9

## First build it occurred

First (and only) occurrence in scanned window: [build 1406427](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1406427), finished 2026-05-03T09:02:27Z. Not present in builds 1404759, 1403076, 1401195.

**Note:** The failure is on a real tvOS device, not a simulator. Prior builds run on a different device assignment may not exhibit the same timing or filesystem behavior.

## Recommended action

1. **Investigate `TokenForEmptyFilter` test logic**: The test calls `Watch("")` and asserts the resulting token is not triggered. On a real tvOS device, file-system watcher events (like kqueue/FSEvents) may fire spuriously on empty patterns — check whether `PhysicalFileProvider.Watch("")` on tvOS/macOS returns a token that fires immediately.
2. **Check for recent changes** to `PhysicalFileProvider.Watch` or the underlying `IChangeToken` implementation in `src/libraries/Microsoft.Extensions.FileProviders.Physical/`.
3. If this is a device-specific intermittent failure, monitor for recurrence and add `[ActiveIssue("https://github.com/dotnet/runtime/issues/", TestPlatforms.tvOS)]` if it recurs.
4. Area owner: `@dotnet/area-extensions-fileproviders`

> [!NOTE]
> This issue was automatically filed by the CI outer-loop failure scanner (workflow run 25391528616).

> [!NOTE]
>
> 🔒 Integrity filter blocked 2 items
>
> The following items were blocked because they don't meet the GitHub integrity level.
>
> - [#90803](https://github.com/dotnet/runtime/issues/90803) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#88027](https://github.com/dotnet/runtime/issues/88027) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
>
> To allow these resources, lower `min-integrity` in your GitHub frontmatter:
>
> ```yaml
> tools:
> github:
> min-integrity: approved # merged | approved | unapproved | none
> ```
>
>

> Generated by [CI Outer-Loop Failure Scanner](https://github.com/dotnet/runtime/actions/runs/25391528616/agentic_workflow) · ● 10.6M · [◷](https://github.com/search?q=repo%3Adotnet%2Fruntime+is%3Aissue+%22gh-aw-workflow-call-id%3A+dotnet%2Fruntime%2Fmobile-scan%22&type=issues)