feat(daemon): pluggable secret store backends

Related

• Builds on PR #113 (DualSecretStore, secret_name / secret_store, DR-047)
• Sibling UI follow-up: #115

Summary

The daemon today hardcodes a fixed set of secret backends (memory, keychain, plus env as a configure/reference path). The core SecretStore interface is injectable for library/CoreState consumers, but the running daemon and the public secret_store vocabulary are not pluggable.

Operators and embedders may want additional backends (e.g. HashiCorp Vault, cloud KMS/Secrets Manager, org-specific secret services) without forking Abbenay.

Desired outcome

• A documented extension point for registering additional secret-store backends
• Daemon configuration (and/or plugin discovery) that can select a backend by name
• Existing memory / keychain / env behavior preserved as built-ins
• Auth, audit ([Audit] secret changed), and list/presence-only HTTP semantics unchanged

Non-goals (for this issue)

• Implementing a specific third-party backend (Vault, AWS SM, etc.) — those can be follow-ups once the plug-in surface exists
• Dedicated Secrets UI — see #115

Acceptance criteria

• Documented interface / registration API for custom backends
• Daemon can resolve secret_store: <custom-id> to a registered implementation
• Built-in backends still work; unknown store IDs fail closed with a clear error
• Tests cover registration + selection; no secret values in logs

Start by reading PR #113 and the existing SecretStore interface and CoreState injection path described in the issue, then trace how the daemon resolves the public secret_store vocabulary. Done means a documented registration API, custom-ID selection, preserved built-ins, fail-closed unknown IDs, and tests for registration and selection without secret values in logs.