fix(security): require ToolAccessPolicy deny-list and protected-path policies

[Aaronontheweb]

Problem

ToolAccessPolicy took its two shell security controls as optional constructor
parameters:

• shellCommandPolicy (the hard deny-list), and
• toolPathPolicy (the protected-path policy).

Both were consumed with the null-tolerant pattern the constitution warns about:

• if (_shellCommandPolicy is not null && …) — a null skips the hard-deny gate.
• _toolPathPolicy?.CommandReferencesDeniedPath(…) == true — a null makes the
  protected-path check evaluate to false and pass.

A ToolAccessPolicy built without those deps therefore silently allows commands
the deny-list and protected-path rules should block. Two in-repo fallback
constructions did exactly that:

• DispatchingToolExecutor had a 1-arg convenience constructor that built a policy
  with no toolPathPolicy.
• SubAgentActor fell back to the same shape when no policy was injected.

Production is not breached today — SubAgentSpawner threads the fully-wired policy
from Program.cs into every sub-agent — but the optional parameters leave the door
open for any future or edge caller to get a silently degraded policy. On a
security control, a null must fail loudly, not fail open.

Fix

Make the two security dependencies required so the type system, not a call-site
convention, guarantees they are present:

• ToolAccessPolicy now takes shellCommandPolicy and toolPathPolicy as required
  parameters (reordered ahead of the optional ones) and rejects null with
  ArgumentNullException. The consumption sites drop their null guards.
• The DispatchingToolExecutor(registry) convenience constructor is removed;
  callers must pass a policy.
• SubAgentActor and SubAgentActor.CreateProps require a policy — the null
  fallback is gone.

Tests

ToolAccessPolicyRequiredDependenciesTests adds:

• Constructor_requires_shell_command_policy — a null deny-list is rejected.
• Constructor_requires_tool_path_policy — a null protected-path policy is rejected.
• Shell_referencing_protected_path_is_denied_when_dependencies_are_wired — a
  positive control proving the protected-path deny fires when the policy is present
  (the block the fallbacks silently lost).

The two contract tests fail before the fix (the constructor accepts null) and pass
after.

Scope

This PR is limited to the required-security-dependency fix. It came out of an
investigation into failing tool calls on self-hosted models; the other findings
from that investigation (approval re-drive of parallel "messy" tool batches, and a
history-ordering issue that lets a failed tool batch wedge a session on strict
OpenAI-compatible endpoints) are tracked separately and are not part of this change.