Python: [Feature]: Supply-chain: MCP server allowlist & signature-verification primitive

Nobody has claimed this yet.

### Description

## Context

The framework currently supports MCP server integration via `MCPClient` (Python) and `ModelContextProtocol` (NuGet). Library versions are pinned (`mcp[ws]==1.27.0`, `ModelContextProtocol Version="1.1.0"`) — but **the MCP servers themselves** that a deployer connects to are not subject to any framework-level trust governance:

- No allowlist primitive (any URL works)
- No signature/pubkey verification
- No version-pinning guidance for *servers* (vs. the MCP library)
- No documented threat model in `SECURITY.md` or `TRANSPARENCY_FAQ.md` for MCP source trust

The closest existing item is #4927 (declarative MCP binding ergonomics), which is adjacent but distinct — that's about *referencing* servers, this is about *trusting* them.

## Why this matters now (2026 supply-chain precedents)

The MCP ecosystem has had three publicly-discussed incidents in the last ~6 months:

1. **CrewAI CVE-2026-2275 / CVE-2026-2287** — prompt injection chained into RCE via silent sandbox degradation. The trust path between agent runtime and untrusted MCP-sourced tooling was the core enabling condition.
2. **Postmark MCP rug-pull** — a previously-trusted MCP server published a malicious update; downstream deployments inherited it because no version pinning or signature check was in place.
3. **PhantomRaven "slopsquatting"** — typosquatted MCP server names targeting the LLM-suggestion pathway (LLMs hallucinating package/server names that attackers then register).

In each case, deployer-side mitigation alone was insufficient because there was no framework primitive to enforce it.

## Proposed primitive (sketch — open to other shapes)

A built-in allowlist + verification layer at the `MCPClient` boundary:

```python
client = MCPClient(
server_url="https://mcp.example.com",
trust_policy=MCPTrustPolicy(
allowed_origins=["https://mcp.example.com"], # exact-match or glob
require_signature=True, # PKI / sigstore
pinned_version="1.4.2", # or hash
on_violation="halt", # halt | warn | ignore
),
)
```

For .NET, an equivalent `MCPTrustPolicy` builder option on `ModelContextProtocolClientFactory`.

**Acceptance criteria suggestion:**
- Default `on_violation="halt"` for new clients (fail-closed)
- Documented threat model in a new ADR
- Sample showing the verification flow against a public MCP registry
- Test coverage for: unknown origin, version mismatch, signature mismatch, pubkey rotation

## Regulatory context

This control maps to:
- **EU AI Act Art. 15** (third-party components)
- **ISO 27001:2022 A.5.19–22** (supplier relationships)
- **NIST AI RMF Map 3.4** (AI supply chain risk)
- **SOC 2 Type II CC9.2** (third-party risk)

Without a framework-level primitive, deployers building under any of these frameworks must implement the equivalent layer themselves — which is fragile and not easy to audit consistently.

## Source

Found during an internal Aegis Release Gate v2.5 security assessment of MAF `python-1.3.0` + `dotnet-1.6.1`. Happy to share more findings or PoC test cases if helpful.

Cross-link: #4927.

### Code Sample

```markdown
A built-in allowlist + verification layer at the `MCPClient` boundary:

client = MCPClient(
server_url="https://mcp.example.com",
trust_policy=MCPTrustPolicy(
allowed_origins=["https://mcp.example.com"], # exact-match or glob
require_signature=True, # PKI / sigstore
pinned_version="1.4.2", # or hash
on_violation="halt", # halt | warn | ignore
),
)
```

### Language/SDK

Both

Start with the existing MCPClient and ModelContextProtocolClientFactory entry points, then review SECURITY.md and TRANSPARENCY_FAQ.md for current MCP trust guidance. Define the policy shape and threat model before implementing the Python and .NET boundaries. Done means an ADR, registry verification sample, fail-closed default, and tests for origin, version, signature, and key-rotation failures.

Written by the indexing model from the issue text.