v0.5.0 — Signed manifests

[marmar9615-cloud]

Tracking issue for the v0.5.0 release line. Mirrored in-tree at
docs/issues/v0.5.0-signed-manifests.md
so design docs and PRs can link to a stable path regardless of issue
renumbering.

Goal

Design — and later implement — signed AgentBridge manifests so
agents can verify a manifest's authenticity and integrity before
trusting any action it declares. The first PR is design-first; no
runtime change ships in it.

Why

Web apps publish machine-readable manifests at
/.well-known/agentbridge.json. Agents read the manifest and call
the actions it declares. Today, the only thing standing between a
malicious manifest and an agent is transport security plus origin
pinning. That leaves real risks unaddressed:

• A compromised CDN cache or a stolen TLS cert lets an attacker
  serve a substituted manifest with no protocol-layer signal.
• A stale manifest (replayed long after rotation) is
  indistinguishable from a fresh one.
• An adopter operating across multiple environments has no way to
  verify "this manifest is the one our build pipeline produced."

Signed manifests close those gaps by binding a manifest to a
publisher key the agent can verify offline.

Initial deliverable

Design-first PR:

• Design doc: docs/designs/signed-manifests.md.
• ADR: docs/adr/0002-signed-manifests.md.
• Threat model update for "tampered / stale / untrusted manifest"
  (T1 in docs/threat-model.md).
• v1 readiness update — signed manifests move from "planned" to
  "design-in-progress".
• Implementation plan + test plan inside the design doc.

No runtime change. No package version bump. No npm publish.
Unsigned-manifest behavior is unchanged.

Security requirements (non-negotiable)

• No private keys in manifests, ever.
• No secrets in docs or examples; all sample keys clearly labeled
  non-production and regenerable.
• Key rotation is a first-class design concern.
• Verification failure modes are documented for each case (missing
  signature, invalid signature, expired manifest, unknown key id,
  malformed public key, base-URL/fetch-origin mismatch).
• Replay / staleness is addressed via a freshness model
  (timestamp + max-age or equivalent).
• Verification is additive — it does not bypass the existing
  confirmation gate, origin pinning, target-origin allowlist, audit
  redaction, stdio stdout hygiene, or HTTP transport auth/origin
  checks.

Non-goals

• No full implementation in this PR.
• No central certificate authority in the first design unless
  explicitly justified.
• No blockchain requirement.
• No removal of unsigned-manifest support yet.
• No package version bump in the design PR.

Reference docs

• docs/v1-readiness.md
• docs/threat-model.md
• docs/security-configuration.md
• docs/roadmap.md
• docs/releases/v0.4.0.md

Acceptance for the design PR

• Design doc and ADR committed.
• Roadmap, v1 readiness, threat model, production readiness,
  security configuration all link to the design.
• No runtime behavior change. Unsigned manifests still validate.
• Safety invariants intact. No package version bump.

Acceptance for v0.5.0 release (later)

• Manifest signature envelope implemented per the chosen design.
• Canonical-JSON serializer shipped from core with cross-language
  test vectors.
• SDK exposes signing/verification APIs.
• Scanner downgrades unsigned manifests; flags invalid signatures
  as errors.
• MCP server verifies signatures when present; high-assurance
  deployments can opt into --require-signature.
• CLI gains sign, verify, and keys (generate|list|rotate).
• Threat model T1 downgraded from "open" to "mitigated for signed
  manifests".
• Tests cover every requirement in the design's testing plan.
• Release notes flag signing as opt-in and document new env vars.
• Trusted Publishing flow exercised end-to-end for v0.5.0.