feat(daemon): pluggable secret store backends

[cidrblock]

Related

• Builds on PR feat(daemon): namespaced memory + keychain secret stores #113 (DualSecretStore, secret_name / secret_store, DR-047)
• Sibling UI follow-up: feat(ui): disassociate secret storage from provider configuration #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 feat(ui): disassociate secret storage from provider configuration #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

[cidrblock]

Sibling follow-up for UI: #115. Builds on #113 / DR-047.

[cidrblock]

PR #113 now uses discrete namespaced resolve via (secret_store, secret_name) and a NamespacedSecretStore surface (getFrom / setIn / …). That is the intended foundation for registering additional backend ids here.

[cidrblock]

Naming update on #113: DualSecretStore → SecretStoreRegistry (daemon/secrets/registry.ts). Built-ins remain separate MemorySecretStore + KeychainSecretStore; env stays a credential source, not a registry entry.