feat(cli): allow CLI verify to accept a trusted public key

[Miracle778]

What

Adds --public-key PATH to manifest verify, so the CLI can pass a trusted raw Ed25519 public key into the existing verifier and the documented local keygen -> sign -> verify workflow can return VALID.

Why

Closes #182.

manifest keygen produces private.hex and public.hex, and manifest sign can sign with the private key — but manifest verify previously had no way to consume the generated public.hex. Because the verifier is fail-closed by design, a signed manifest without a trusted key correctly returned:

{
  "result": "UNVERIFIABLE",
  "signature_verified": false
}

The same manifest already verified as VALID through the SDK when VerificationContext.trusted_keys was provided, so the verifier capability existed — this was a CLI exposure gap, not a verifier gap.

Before:

manifest keygen -d ./keys/
manifest sign draft.json --key keys/private.hex -o signed.json
manifest verify signed.json   # UNVERIFIABLE

After:

manifest verify signed.json --public-key keys/public.hex   # VALID

{
  "result": "VALID",
  "signature_verified": true
}

The CLI derives key_id = sha256(public_key_bytes) and public_b64url = base64url(public_key_bytes, no padding), then passes trusted_keys={key_id: public_b64url} into VerificationContext. It does not change verifier semantics, and it does not implicitly look up public.hex — the trust root stays explicit.

Spec impact

None. SDK-only change; verifier semantics are unchanged.

Test plan

• pytest -v passes
  • tests/test_cli.py tests/test_public_api.py tests/test_verify.py -> 41 passed
  • tests/test_examples.py -> 33 passed
• mypy src/agent_manifest passes — not installed locally; left to CI
• ruff check src/ tests/ passes — not installed locally; left to CI
• New or updated tests cover the change — added CLI tests in python/tests/test_cli.py:
  • signed manifest without --public-key remains UNVERIFIABLE
  • matching --public-key returns VALID
  • wrong --public-key returns MISMATCH
  • malformed public key file fails cleanly (no traceback)
  • missing public key file fails cleanly (no traceback)
• If spec change: CHANGELOG.md updated — N/A (no spec change)

DCO

All commits in this PR are signed off (git commit -s). By submitting this PR I certify the Developer Certificate of Origin.

---

Notes / intentional non-goals

This first CLI option is intentionally Ed25519-only. It accepts the raw public key hex format already emitted by manifest keygen, matching the existing CLI sign --key Ed25519 workflow.

This PR intentionally does not add:

• default lookup of public.hex in the working directory
• multi-key trust stores
• PKI / issuer registry integration
• ML-DSA-65 or hybrid (hybrid-Ed25519-ML-DSA-65) public key support

The SDK and specification already account for ML-DSA-65 and hybrid-Ed25519-ML-DSA-65, but exposing those safely in the CLI needs a separate key-input / trust-store design (key file formats, whether the CLI should accept individual flags or a trust-store file, how key IDs map to algorithms, and how production issuer registries / PKI / KMS / transparency-log trust roots map into CLI inputs).

That broader CLI/trust-store shape is a project-level interface decision, not something this small contributor PR should define implicitly. Multi-algorithm CLI support can follow once the maintainers decide the desired key/trust-store interface.

Files changed

README.md
docs/api-reference/cli.md
docs/getting-started.md
python/src/agent_manifest/cli.py
python/tests/test_cli.py

[imran-siddique]

LGTM — clean, well-scoped fix. Closes the keygen→sign→verify CLI loop, Ed25519-only is the right call for now, and the intentional non-goals are well-documented. Merging.