feat(credentials): read-only 1Password credential source for local gateways

[ilaigold]

User Story

As a developer running OpenShell on my laptop,
I want to attach a provider whose key already lives in my 1Password
(for example op://Private/Anthropic/credential),
so that I don't copy the key into another store, and a key I rotate in 1Password reaches
new sandboxes.

Problem Statement

OpenShell can only store credentials that are handed to it. #1931 rejected "provider-authored
references to existing backend secrets", so there is no way to use a secret the user already
keeps in a password manager.

Impact / Why This Matters

• Individual developers keep API keys in password managers, and 1Password is the most common
  one among developers.
• Today they paste each key into openshell provider create, or export it for
  --from-existing (for example with op run). That makes a second copy that doesn't follow
  rotation and passes the key through the shell.
• Docker Sandboxes ships this for the same audience. sbx secret set anthropic --ref 'op://Work/Anthropic/credential' is resolved on the host and cached, and the sandbox only
  sees a placeholder.

Proposed Design

This is the local-gateway case of the narrower model proposed in the 2026-08-27 comment on
#1931: sources declared by the gateway owner, read-only, and no backend addressing in provider
config beyond what the owner allowed. On a laptop gateway, the owner and the person creating
providers are the same person.

• The gateway owner enables a 1Password source in gateway config and limits it to named
  vaults.
• A provider credential points at that source and an item/field in an allowed vault instead
  of carrying a value. The exact CLI syntax is up to maintainers.
• The source is read-only: OpenShell never creates, edits or deletes 1Password items.
• The gateway reads the value when a sandbox starts. Placeholders and endpoint binding stay
  exactly as they are.
• Sign-in uses the 1Password desktop app (the user approves once per session, for example
  with Touch ID) or a service account token the owner provides.
• If 1Password is locked or unreachable, the sandbox's provider readiness says why. There is
  no silent fallback.

Acceptance Criteria

• A provider can be created from a 1Password reference without the value passing through
  the CLI arguments or shell environment.
• References outside the vaults the owner allowed are rejected at create time.
• OpenShell never writes to 1Password.
• After a key is rotated in 1Password, newly started sandboxes use the new value, and the
  docs say what happens to running ones.
• The sandbox only ever sees a placeholder, as today.
• A locked or unavailable 1Password gives a clear readiness reason.

Alternatives Considered

• A 1Password credential driver under the current model, where OpenShell writes its own
  items into a vault. This keeps "the gateway owns storage", but users gain nothing: they
  still paste every key.
• A sync on the host that reads op:// and pushes the value with
  openshell provider update. This works today without OpenShell changes, but every client
  has to build it, and the value is still copied.
• op run -- openshell provider create --from-existing. This works today as a one-time
  copy, but rotation is not followed.

Agent Investigation

• feat: add credential drivers for provider secret storage #1931, "Alternatives Considered", records the rejection of references. The 2026-08-27
  comment there proposes owner-declared, read-only sources and surveys similar systems (ESO,
  Secrets Store CSI, Vault Agent, and others).
• proto/credential_driver.proto handles are created by the gateway ("must not be authored
  by users"), so this needs a gateway-side change, not only a new driver.
• 1Password has official SDKs for Go, JS and Python, including desktop-app authentication, but
  no Rust SDK. A Rust implementation would call the op CLI, as Docker does, or the
  1Password Connect API.

I'd like to implement this if maintainers agree on the model.

Checklist

• I've reviewed existing issues and the architecture docs
• This is a design proposal, not a "please build this" request