Add a Bitwarden-backed secrets manager to RPA.Robocorp.Vault

[mikahanninen]

Problem

RPA.Robocorp.Vault currently ships exactly two BaseSecretManager implementations: FileSecrets (local YAML/JSON, dev-only) and RobocorpVault (Control Room-backed). There is no self-hosted, cloud-vault-backed option that doesn't depend on Control Room — which matters more now that Robocorp's Control Room is being folded into Sema4.ai's platform rather than continuing as a standalone product. Teams running bots outside that specific platform (or wanting to avoid vendor lock-in for secrets) have no supported way to plug in a widely-used self-hosted/cloud password manager as a backend.

Idea

Add a new BaseSecretManager subclass that reads secrets from Bitwarden (a widely adopted, API-scriptable, open-source-friendly password manager with an official CLI), so a bot can do:

from RPA.Robocorp.Vault import Vault

vault = Vault(default_adapter="Bitwarden")
creds = vault.get_secret("my-service-credentials")

and get back a Secret populated from a Bitwarden vault item (login fields + custom fields), the same shape bots already get from FileSecrets/RobocorpVault today, so switching backends is a one-line config change.

Potential solution design

• New adapter class BitwardenVault(BaseSecretManager) in RPA.Robocorp.Vault (or a new RPA.Robocorp.Vault.bitwarden submodule if the dependency footprint should be kept optional/lazily-imported).
• Auth/session handling: shell out to the official bw CLI (unlock via API key or master password + 2FA, cache an unlocked session token for the process lifetime) rather than reimplementing Bitwarden's crypto — mirrors how other rpaframework integrations wrap vendor CLIs/SDKs instead of the raw protocol.
• Map a Bitwarden item's login username/password plus any custom fields into the existing Secret mapping interface, so secret["username"], secret["password"], and arbitrary custom fields all resolve the same way RobocorpVault secrets do today.
• Config surface: vault URL (for self-hosted Bitwarden/Vaultwarden instances), org/collection filtering, and item lookup by name or ID — exposed via the same environment-variable/config pattern RobocorpVault uses (RPA_SECRET_MANAGER=Bitwarden, etc.).
• Error handling: distinct exceptions for "CLI not installed," "vault locked," "item not found" so bots can fail with an actionable message instead of a raw subprocess error.
• Make the Bitwarden CLI dependency optional (lazy import / extra), since not every rpaframework install needs it, following the pattern of other optional integrations in the package.

Why this belongs in core

Secrets management is a cross-cutting concern every bot needs, and today the only non-local option is tied to one specific control plane. A self-hosted-friendly, open-source-adjacent backend gives users a real choice instead of a single point of vendor lock-in.