fix(deps): require agent-manifest>=0.6.1 and report unappraisable manifests clearly

[imran-siddique]

Picks up the verifier crash fixed in agent-manifest 0.6.1 (agent-manifest#245), which cMCP is exposed to.

Why this matters here specifically

verify_agent_manifest_binding calls the SDK verifier on a peer-supplied manifest. Before agent-manifest 0.6.1, a manifest declaring ML-DSA-65 or hybrid-Ed25519-ML-DSA-65 reached _require_oqs() and crashed the SDK with an uncaught RuntimeError on any install without the optional [pq] extra, which is the default. So this path answered a crash rather than a rejection, triggered by input a peer controls, with no valid signature or trusted key needed.

The existing floor was >=0.5, which merely allows 0.6.1. The comment in pyproject.toml says why it is now a requirement rather than a preference.

Behaviour change

Fail-closed behaviour is unchanged: cMCP already rejected UNVERIFIABLE, which is what the SDK now returns. What changes is the message.

UNVERIFIABLE previously raised ConfigError("Agent Manifest signature verification failed"), which is misleading. The signature did not fail; it could not be checked, either because there is no trusted key for it or because this build cannot run the algorithm. Those need opposite operator responses: install an extra or fix the trust anchor, versus reject a bad manifest. It now raises "Agent Manifest signature could not be verified" and appends the verifier's own reason:

ConfigError: Agent Manifest signature could not be verified: signature algorithm
ML-DSA-65 is not supported by this build, so the signature could not be appraised: ...

The MISMATCH-with-signature-detail path keeps "signature verification failed", so a genuinely bad signature still reads that way.

Verification

Exercised through cMCP's own entry point, not the SDK's, with agent-manifest 0.6.1 resolved from the new floor and no [pq] extra installed. A peer-supplied ML-DSA-65 manifest yields the ConfigError above rather than a RuntimeError.

• 892 passed, 6 skipped (was 891 before; one new regression test pins this path so the floor cannot be silently lowered)
• Built in a throwaway venv from the edited pyproject.toml, confirming the floor resolves to 0.6.1