Motivation & Context

The HarnessAgent previously enabled its FileAccessProvider by default (opt-out via HarnessAgentOptions.DisableFileAccess), implicitly rooting a FileSystemAgentFileStore at {cwd}/working unless the caller disabled it. File access grants the agent read/write/delete tools over a working directory, so enabling it implicitly is surprising and violates least-privilege.

As part of preparing the harness for release, file access is now opt-in: it is only wired up when the caller deliberately supplies a FileAccessStore. This mirrors the existing opt-in pattern used for BackgroundAgents (presence of the value enables the provider; no Disable* flag).

Description & Review Guide

• What are the major changes?

  • HarnessAgentOptions: removed DisableFileAccess; reworded FileAccessStore docs to describe opt-in behavior; added FileAccessProviderOptions? FileAccessProviderOptions so callers can configure the provider (instructions, disable write tools, approval).
  • HarnessAgent: FileAccessProvider is added only when FileAccessStore is set — no implicit {cwd}/working default store is ever created. The supplied FileAccessProviderOptions are passed through. Class <remarks> updated to list FileAccess under the optional/enabled-via-options providers.
  • Tests: dropped all DisableFileAccess usage; the "all defaults" test now asserts FileAccessProvider is absent by default; the include/exclude/custom-store tests are now store-driven, plus a new test covering FileAccessProviderOptions.
  • Samples: removed now-redundant DisableFileAccess = true lines; the "all features" code-execution sample now explicitly enables file access via a FileAccessStore; corrected comments/README describing the old default behavior.

• What is the impact of these changes?

  • Breaking change for users of the (experimental) harness: agents no longer receive file access unless a FileAccessStore is supplied, and DisableFileAccess is removed. Samples that need file access set FileAccessStore explicitly.

• What do you want reviewers to focus on?

  • The wiring change in HarnessAgent.BuildContextProviders and the sample updates that keep file access working where it is intended.

Related Issue

Related to #7092 (the issue covers both .NET and Python, so this PR does not close it).

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.