.NET: [Feature]: provide an official sandbox abstraction for command/tool execution

# Proposal: sandboxed command execution to reduce approval fatigue

## Summary

I would like to suggest adding an official sandbox abstraction for command/tool execution.

This is a practical pattern. DSH uses this direction, and local experiments show that it can significantly reduce approval frequency: run commands in a restricted sandbox by default, and only ask the user for approval when the command needs to exceed the sandbox policy.

## Why

For coding agents and local automation, asking the user to approve every command is too noisy. Many commands are safe if they are constrained:

- read-only commands
- commands that only write inside the workspace
- commands that cannot modify files outside the workspace
- commands whose child processes are killed with the run

When a command is blocked by the sandbox, the tool can return a structured restriction result. The agent can then ask for a scoped elevation, such as retrying this one command with broader permissions.

This gives a better flow:

1. Run safely by default.
2. Avoid approval for normal safe operations.
3. Ask for approval only when sandbox limits are hit.
4. Keep elevation explicit and scoped.

## Windows reference

On Windows, one possible implementation is based on OS security primitives:

- restricted token
- restricting/capability SIDs
- workspace ACL grants
- private temp directory grants
- Job Object cleanup

This approach is worth referencing because it is not just command-string filtering. It uses the OS permission model to enforce the boundary.

## Proposal

Could MAF provide a common sandbox contract that command tools can use?

For example:

```csharp
public interface IAgentCommandSandbox
{
Task RunAsync(
CommandRequest request,
SandboxPolicy policy,
CancellationToken cancellationToken);
}
```

MAF could provide a default implementation or sample implementation, while still allowing developers to plug in their own backend: Windows restricted token, container, remote executor, enterprise policy service, etc.

This could work well with `AIContextProvider` and `ToolApprovalAgent`: the provider exposes command tools with the current request/workspace policy, and approval is only needed when the sandbox reports that elevation is required.

## Questions

- Is this kind of sandbox abstraction in scope for MAF?
- Could MAF provide an official contract, even if platform implementations remain pluggable?
- Should sandbox restriction results integrate with tool approval so agents can request scoped elevation?

I think this would satisfy many local-agent use cases by reducing repeated approvals while still keeping risky actions explicit.