#1109 Vault: native secret-read access audit trail

What's missing: swamp vault has no way to audit secret reads (who/what/when retrieved a secret). The VaultProvider interface is {get, put, list, getName} with no read-event hook; the CLI exposes inspect/annotate (write-time metadata + manual provenance notes) but no audit/log/history subcommand. inspect --json shows size/type/annotation/refresh-hook config and the annotation's updatedAt, but no lastReadAt/readCount/readBy/event list.

Use case / why it matters: Building a security posture for an autonomous agent fleet where scoped credentials (fine-grained GitHub PATs, API keys) live in swamp vault. A core requirement is proving "which automation read which secret, when" — for least-privilege verification and after-the-fact review. Today that trail must be hand-built by wrapping every vault.get() in a custom model method that logs to a datastore resource, and every caller must be disciplined to route through it (raw swamp vault read-secret bypasses the log). Native read-auditing would make this a first-class, un-bypassable capability.

Proposed shape (suggestion, not prescription): an optional per-vault or per-secret "audit reads" flag that appends {secretKey, reader/caller context, timestamp, operation} to an append-only datastore resource on each get(), queryable via a swamp vault audit <vault> or swamp vault log <vault> subcommand. For provider backends that already emit access logs (aws-sm→CloudTrail, azure-kv→Azure Monitor), swamp could surface/normalize those instead of duplicating.

Current workaround: thin secretAccess.read model method that calls vault.get() + writes a datastore resource + returns the value; all automation routes through it. Works but is bypassable and per-consumer boilerplate.

Context: local_encryption backend specifically has no external audit source, so the wrapper is the only option there today.