TaskHost file access reporting ignores BuildParameters.ReportFileAccesses

### Summary

When a task runs in a TaskHost, file accesses reported through `EngineServices.ReportFileAccess` are collected and replayed unconditionally, ignoring `BuildParameters.ReportFileAccesses`. The equivalent in-proc code path does honor the flag. The same task therefore behaves differently depending only on where it happens to be scheduled.

This was found while investigating #14824, and it is the reason that defect crashed builds which had never asked for file-access reporting.

### Details

The in-proc engine gates on the build parameter (`src/Build/BackEnd/Components/RequestBuilder/TaskHost.cs`):

```csharp
public void ReportFileAccess(FileAccessData fileAccessData)
{
IBuildComponentHost buildComponentHost = _taskHost._host;
if (buildComponentHost.BuildParameters.ReportFileAccesses)
{
((IFileAccessManager)buildComponentHost.GetComponent(BuildComponentType.FileAccessManager)).ReportFileAccess(fileAccessData, buildComponentHost.BuildParameters.NodeId);
}
}
```

The TaskHost process does not (`src/MSBuild/OutOfProcTaskHostNode.cs`):

```csharp
public void ReportFileAccess(FileAccessData fileAccessData)
{
_taskHost._fileAccessData.Add(fileAccessData);
}
```

Neither does the replay in the owning worker node (`src/Build/Instance/TaskFactories/TaskHostTask.cs`):

```csharp
private void HandleTaskHostTaskComplete(TaskHostTaskComplete taskHostTaskComplete)
{
#if FEATURE_REPORTFILEACCESSES
if (taskHostTaskComplete.FileAccessData?.Count > 0)
{
IFileAccessManager fileAccessManager = ((IFileAccessManager)_buildComponentHost.GetComponent(BuildComponentType.FileAccessManager));
foreach (FileAccessData fileAccessData in taskHostTaskComplete.FileAccessData)
{
fileAccessManager.ReportFileAccess(fileAccessData, _buildComponentHost.BuildParameters.NodeId);
}
}
#endif
```

`TaskHostConfiguration` carries no equivalent of `ReportFileAccesses`, so the TaskHost has no way to know the flag is off.

### Impact

1. **Inconsistent behavior.** A task that calls `ReportFileAccess` is a no-op in-proc when reporting is disabled, but is collected, serialized across the pipe and replayed into the `FileAccessManager` when the same task runs in a TaskHost — which now happens by default for every task not annotated with `MSBuildMultiThreadableTaskAttribute` under `-mt`.
2. **Wasted work.** Every TaskHost task completion pays for serializing a `List` even when nothing will consume it.
3. It turned #14824 from "corrupted data for opted-in users" into "builds crash with `MSB4018` / `MSB1025` even without `-reportfileaccesses`". I reproduced that crash with `MSBuild.exe repro.proj` using nothing but a `TaskHostFactory` `UsingTask` — no `-mt`, no `-reportfileaccesses`.

### Expected behavior

`ReportFileAccess` should be a no-op end to end when `BuildParameters.ReportFileAccesses` is `false`, regardless of where the task executes.

### Suggested fix

Plumb the flag into `TaskHostConfiguration` so `OutOfProcTaskHostNode.EngineServicesImpl.ReportFileAccess` can skip collection entirely, and gate the replay in `TaskHostTask.HandleTaskHostTaskComplete` on `_buildComponentHost.BuildParameters.ReportFileAccesses` for older/mismatched task hosts.

Note that gating alone would only have hidden #14824; the deserialization fix there is still required.

Start with src/Build/BackEnd/Components/RequestBuilder/TaskHost.cs to compare the in-proc behavior, then trace TaskHostConfiguration and src/MSBuild/OutOfProcTaskHostNode.cs through src/Build/Instance/TaskFactories/TaskHostTask.cs. Verify how the flag reaches the TaskHost and how completion data is replayed. Done means disabled reporting is a no-op in both execution paths, while enabled reporting still reaches FileAccessManager.

Written by the indexing model from the issue text.