#412 Annotating vault items should be a first-class swamp operation

Problem

When a secret is stored in a swamp vault, there is no swamp-native way to attach provenance metadata to it — what the secret is for, which downstream model consumes it, when it was minted, what credential it supersedes, where the upstream identity lives, etc.

To attach that metadata today, you have to drop out of swamp and use the backend's own CLI/UI directly. For the @swamp/1password provider that means running op item edit ... --url "..." notesPlain="..." against the underlying Secure Note swamp created. This works, but:

1. It bypasses swamp's abstraction — the next human looking at a vault entry has to know which backend is in play and which native CLI to reach for.
2. It only exists for 1Password. AWS Secrets Manager, HashiCorp Vault, and Azure Key Vault each have their own annotation primitives (tags, metadata, custom fields) and the same conceptual operation has a different shape in each — or is missing entirely.
3. It is undiscoverable from swamp's own docs.

Concrete motivating case

I just stored a GitHub App private key PEM in a swamp 1Password vault for a downstream swamp model to consume on every audit run. The provenance I wanted to attach to that vault entry:

• URL to the App's settings page in GitHub
• App ID and installation ID
• Date minted + by whom
• Name of the swamp model that consumes it (@hivemq/github/installation-token)
• Pointer to the credential it supersedes (GH_TOKEN)

Every one of those is information the next on-call engineer will need in a year when this secret expires or has to be rotated. Today none of it lives in swamp.

Proposed solution

Make annotation first-class. Sketch:

swamp vault annotate <vault-name> <key> \
  --url <u> \
  --note <multiline-text> \
  --label <k=v>
swamp vault inspect <vault-name> <key>          # show annotations

Implementation scope:

• New CLI subcommand under swamp vault.
• New annotation primitive on the VaultProvider interface (4 abstract methods: set/get URL, set/get notes, set/get labels, plus a single fetch-all for inspect). Optional in the interface so existing custom vault extensions don't break.
• Provider-side adapters mapping the abstract primitives onto each backend:
  • @swamp/1password: URL → item url, notes → notesPlain, labels → custom labeled fields.
  • AWS Secrets Manager: labels → resource tags, notes → Description.
  • HashiCorp Vault: labels + notes → custom_metadata on the KV v2 entry.
  • local_encryption: store annotations alongside the encrypted blob.
• Documentation: add to the vault skill and the provider reference docs so the operation is discoverable.

Alternatives considered

• Just documenting "use op for 1Password": loses cross-backend coherence and doesn't help users of other vault backends.
• Embedding annotation conventions in a separate vault-annotations extension: adds another concept users have to learn; weaker discoverability.

The CLI/provider primitive feels right because annotation is fundamentally part of how operators use a vault — not a separable concern.