Capability registry + ed25519 token gate enforced on every host call

[tayebmokni]

Summary

Implement capability tokens (256-bit opaque, ed25519-signed) and the per-host-function capability gate. Every host call verifies its instances caps token before executing; downgraded or revoked plugins lose access immediately because the host rotates signing keys on activate/deactivate.

Design reference

• docs/02-plugin-system.md §6 (intro), §6.1

Acceptance criteria

• CapsToken payload: {plugin, version, instance, caps[], exp}. Encoded as msgpack, signed ed25519 with host key.
• Host ed25519 keypair persisted at startup (cluster-shared if multi-replica; key rotation policy = TBD, separate issue)
• mintCapsToken(plugin) on Activate, renewed on instance creation. Default expiry 5 minutes.
• Host transparently rotates tokens by re-issuing on the guests next call when expiry approaches; guest never sees the secret
• Every host function calls gate.Check(ctx, "db.read:core.posts:read") (or equivalent scope string) at the top; returns -1 no_cap on deny
• Capability grammar (matching manifest §2.2): dotted names (db.read, http.fetch), scopes carried separately (table:op patterns, host allowlists, field allowlists)
• Capability registry: a typed catalog of all v1 capabilities (db.read, db.write, kv, queue, cron, http.fetch, http.serve, email, media.read, media.write, users.read, secrets, cache.invalidate, audit.emit, log, i18n, clock) — see §6 table — each with its scoping semantics, host functions, default quotas
• Revocation: Deactivate invalidates all outstanding tokens for a slug (host key version bump or per-plugin nonce); subsequent calls fail signature verification
• Tests: token forging attempts rejected; expired tokens rejected; scope-mismatch rejected; revoked plugin tokens rejected

Dependencies

#85 (host ABI)

Complexity

L