secrets: warn on deleting a secret bound to an active agent; propagate vault revocation as a runtime generation event

[sergeyenin]

Follow-up from PR #300 review (round 6, non-blocking).

Context

PR #300 made the runtime behavior of secret revocation explicit and honest, but there is a residual operator-experience gap.

Current, documented behavior (docs/reference/configuration.md, "Hot vs restart-required"):

• Deleting/revoking a secret bound to an enabled agent is not a hot revocation. The next reload cannot build a valid registry for that agent, so the whole candidate generation is rejected and last-known-good keeps serving the old key. To revoke access, the operator must disable the agent (hot — the disabled generation activates with the prior key carried forward as a denial-only identity) or restart.
• Deleting a secret while also disabling the agent works hot: the disabled generation activates, gateway returns an attributed 403, and the tenant-API surface rejects the key.

The risk: an operator may interpret `talon secrets set/delete` (or an external vault deletion) as immediate credential invalidation, when for an enabled agent it is not.

Ask

1. Warn on delete-while-bound. When a secret-management command removes/empties a secret that is bound to an agent currently in the active catalog (agent.key.secret_name), print a clear warning: the enabled agent keeps serving on last-known-good until it is disabled or the server restarts; suggest `talon agents disable `.
   • Note: there is currently no `talon secrets delete` command and `SecretStore` has no `Delete` method (only `Set`/`Rotate`); this issue includes adding a first-class delete path with the binding check.
2. Eventually: propagate vault revocation as a runtime generation event. Today reloads are triggered by an agent-file digest change; a vault-only change (rotation or deletion) is invisible to the reloader. Explore surfacing an authoritative vault revocation as its own generation event so an enabled agent's access can be cut without a file touch or restart — e.g. re-resolve keys on an interval or on an explicit `talon secrets`-driven signal, activating a generation that drops/denies the affected agent. Must stay fail-closed and keep the swap-then-evidence + last-known-good invariants.

Acceptance

• Deleting/emptying a bound secret warns, naming the agent and the disable-or-restart remediation.
• Docs cross-reference the warning and the revocation semantics.
• (Stretch) A vault revocation can invalidate an enabled agent's credential at runtime without editing the agent file, as a signed generation event.

Refs: #300, #265.