feat(credentials): add provider credential storage drivers

[TaylorMutch]

Summary

Adds gateway-owned credential storage for Providers v2. New provider credential
writes now persist opaque handles instead of inline secret values, with default
encrypted database storage when no external credential backend is configured and
opt-in Kubernetes Secrets or Vault backends for deployments that want dedicated
secret storage.

Related Issue

Related to #1931

Changes

• Adds a credential driver protobuf contract for store, resolve, delete, list,
  and capability calls.
• Adds gateway credential runtime support for a single active external
  credential driver, in-tree drivers, and UDS-connected external drivers.
• Adds the default encrypted database credential store as
  openshell-driver-db-credstore.
• Adds standalone UDS-capable openshell-driver-kubernetes-secrets and
  openshell-driver-vault binaries, plus in-tree gateway loading.
• Updates Providers v2 create/update/delete paths to store new credential values
  through credential storage and persist internal credential_handles.
• Preserves upgrade compatibility for existing inline/plaintext provider records:
  legacy inline credentials remain readable, config-only updates leave them
  inline, and only newly submitted/rotated credential values move into credential
  storage.
• Rejects user-supplied provider.credential_handles on provider create/update.
• Resolves credential handles at runtime for sandbox provider environments,
  provider refresh, and managed inference routes.
• Updates Helm defaults so no external driver means default encrypted DB
  credential storage, backed by a retained key-encryption-key Secret injected
  into the gateway.
• Adds Helm/Skaffold values and targeted e2e coverage for Kubernetes Secrets and
  Vault credential storage backends. The local Vault e2e path deploys OpenBao as
  a Vault-compatible fixture.
• Updates gateway/provider docs, architecture notes, CI labels, and local test
  tasks for credential driver validation.

Default Behavior

Credential drivers are opt-in for external backends. If
[openshell.gateway].credential_drivers is omitted, the gateway uses the default
encrypted database credential store. The submitted secret is encrypted into a
driver-owned credential object outside the provider record, and the provider
record stores only an opaque handle.

The explicit empty list form, credential_drivers = [], is invalid. Operators
should omit the field for default encrypted DB storage or select exactly one
external backend such as kubernetes-secrets or vault.

Existing provider records that already contain inline plaintext credentials are
still resolved for upgrade compatibility, but new provider creates and credential
updates use credential storage handles.

Testing

• cargo check -p openshell-driver-vault -p openshell-server
• mise run pre-commit
• mise run helm:test
• mise run e2e:kubernetes:credential-drivers
• mise run e2e:rust
• mise run e2e:podman - provider/default credential coverage passed before
  the suite failed in sandbox_create_with_no_keep_cleans_up_after_tty_command;
  isolated rerun of OPENSHELL_E2E_PODMAN_TEST=sandbox_lifecycle mise run e2e:podman reproduced the same Podman cleanup failure.

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated
• Gateway configuration docs updated

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[github-actions]

🌿 Preview your docs: https://nvidia-preview-pr-1986.docs.buildwithfern.com/openshell

[github-actions]

Label test:e2e applied for 153b455. Open the existing run and click Re-run all jobs to execute with the label set. The run will execute the standard E2E suite after building the required gateway and supervisor images once. The matching required CI gate status on this PR will flip green automatically once the run finishes.

[sjenning]

PR Review: feat(credentials): add provider credential storage drivers
PR: #1986
Author: TaylorMutch
Branch: 1931-credential-drivers-implementation/tm -> main
Model: Opus-4.6

Potential Concerns

1. Non-atomic credential+DB operations: The compensating-transaction pattern handles application errors but a process crash between credential storage and DB write leaves orphaned credentials. No reconciliation/GC mechanism exists yet.
2. No KEK rotation path: The code validates key_encryption_key_id on decrypt but provides no migration path for rotating the KEK. All existing envelopes would need re-encryption. Worth tracking for a follow-up.
3. Sequential credential resolution: All three drivers resolve credentials one-at-a-time in a loop. For providers with many keys, this means N round-trips to the backend (especially costly for Vault HTTP calls). The proto supports batch ResolveCredentials but the drivers don't batch internally.
4. Duplicated cleanup logic in provider update: Manual credential cleanup at every error site in update_provider_record_validating (~5 separate error paths). A RAII guard or scope-based approach would reduce the surface for missed cleanups by future maintainers.
5. Vault auth token not cached: Every store/delete/resolve call re-authenticates (reads token file or performs K8s auth login). Under high resolve frequency this could bottleneck or trigger Vault rate limiting.
6. allow_reference_namespace parsed but never enforced in the K8s Secrets driver config. The field is accepted and stored but never checked — operators who set it would get no effect.
7. No OCSF structured logging in either external driver binary. Per project guidelines, credential operations are security-relevant decisions that would normally warrant OCSF events.
8. Proto downgrade risk: Older gateway versions that don't understand credential_handles (field 6) would silently drop handles on write-back, potentially losing credential references.

[sjenning]

I am taking over this effort while @TaylorMutch is away. Superseded by #2437