BYO agents Phase 6: trusted host-side agent plugins / signed driver protocol

Follow-up to #191 (epic). The escape hatch for behavior that genuinely cannot be expressed declaratively (after Phases 1–5 cover the common cases). Lowest priority, and deliberately not the default extension mechanism — dynamic host-side plugins carry trust, signing, ABI/API-stability, supply-chain, and host-execution risk.

Scope (design-first)

• Keep the existing Go SDK path: external consumers can already construct agent.ClientEntry + Plugin (MCPConfig(), Seeder()) and pass them to a registry. Document this as the supported "advanced behavior" route.
• Evaluate a CLI-side external driver protocol instead of loading arbitrary Go plugins: a signed executable the host invokes over a well-defined protocol, with explicit trust boundaries (signature verification, capability scoping). Prefer this over plugin-package loading.

Deliverables

1. A short design doc / RFC weighing: Go SDK only vs. signed external driver vs. (rejected) dynamic Go plugins — with the trust model spelled out.
2. Only after sign-off: implementation.

Non-goals

Do not make arbitrary host-side plugin loading the normal CLI extension mechanism — the declarative path (Phases 1–5) is the default. This issue exists so the epic's full surface is tracked; it should not be picked up before the declarative phases ship and a real need is demonstrated.

Start with the existing Go SDK path around agent.ClientEntry, Plugin, MCPConfig(), Seeder(), and the registry, then review epic #191 and the declarative Phases 1–5. Produce the requested RFC comparing Go SDK only, a signed external driver protocol, and rejected dynamic Go plugins, with trust boundaries and capability scoping. Done means the design is documented and receives sign-off before implementation.