Track external secret-manager integrations (1Password, Bitwarden, Vault, …)

Loose tracking issue for **external secret managers** as candidate value-provider integrations once the v12 plugin SDK lands. Not a commitment to build any — a list to point at when people ask "can Fallout pull secrets from X?".

## Background
ADR-0002 fixes the secret resolution chain:
> CLI → env var → **value-provider attribute** → encrypted parameters file → CredentialStore → prompt

The third step is the integration point for external stores. One precedent in-tree:
- `AzureKeyVaultSecretAttribute` at `src/Fallout.Common/Tools/AzureKeyVault/` — resolves `[Parameter, Secret]` values by fetching from a Key Vault at startup.

Anything fitting the same shape — a remote store reachable by API at build start, returning a string — can ride the same extension point. The v12 plugin SDK ([milestone #7](https://github.com/ChrisonSimtian/Fallout/milestone/7)) is the natural delivery vehicle: each integration is one plugin, owned by whoever needs it, no upstream maintenance burden.

## Candidate integrations (alphabetical, not prioritised)

| Tool | Why track it | Auth model | Notes |
|---|---|---|---|
| **1Password Connect / Service Accounts** | Common in product/eng orgs; the maintainer's workplace uses it | Service-account token + Connect URL, or `op` CLI session | CLI is lowest-friction; service-account API is CI-friendly |
| **AWS Secrets Manager** | Default for AWS stacks | IAM role / access keys | Mature SDK; trivial wrapper |
| **Azure Key Vault** | ✅ **already exists** | Managed identity / service principal | Reference implementation |
| **Bitwarden Secrets Manager** | Maintainer's preference; good for OSS / small teams | Access token + org ID | Distinct from the Password Manager — Secrets Manager is the CI-facing product |
| **Doppler** | Popular with smaller teams; nice DX | Service token | Single-binary CLI, simple REST API |
| **GCP Secret Manager** | Default for GCP stacks | Service-account JSON / workload identity | Symmetric with AWS / Azure |
| **HashiCorp Vault** | The "serious" enterprise option | AppRole / token / OIDC | Most complex auth; biggest payoff |
| **Infisical** | Open-source Doppler alternative; growing | Service token | Worth watching |

## What the framework needs
Already in place:
- ✅ `ValueInjectionAttributeBase` — the base each provider attribute extends (cf. `ParameterAttribute`, `AzureKeyVaultSecretAttribute`).
- ✅ Resolution chain documented in [ADR-0002](../blob/main/docs/adr/0002-cross-provider-auth-and-secret-conventions.md).
- ✅ `[Secret]` marker for log scrubbing (modulo the masking verification still open against the ADR review).

Plausibly needed:
- A small shared "secret value provider" base interface to cut boilerplate.
- Conventions for caching values within one build invocation (some stores are slow / rate-limited).
- A consistent error mode when a store is unreachable (fail-fast vs fall-through).

## Scope
- **In:** keep the list current, accept suggestions, note community interest.
- **Out:** committing to any integration. Each gets its own issue + PR when someone builds it.

Closing condition: when ≥3 ship as v12 plugins and the pattern is proven. Until then, leave open.

## Related
- [ADR-0002 — Cross-provider auth and secret conventions](../blob/main/docs/adr/0002-cross-provider-auth-and-secret-conventions.md)
- v12 milestone — plugin SDK (delivery mechanism)
- Reference impl: `src/Fallout.Common/Tools/AzureKeyVault/`