Support multiple named 1Password vault configurations per owner

[aarondfrancis]

Problem

The 1Password credential provider currently supports one owner-scoped configuration containing one vaultId. Configuring another vault replaces the existing configuration, and secret resolution rejects references outside that selected vault.

This makes least-privilege setups awkward. A user can point Executor at a dedicated automation vault, but may also need selected credentials that remain canonical in a Private, shared, or work vault. Copying those items creates independent copies that do not remain synchronized, while selecting the broader vault exposes more items than Executor needs.

Proposed behavior

Support multiple named 1Password vault configurations per owner, for example:

• executor
• personal
• work

Each configuration would retain its own authentication metadata, vaultId, and display name. Secret references or provider item identifiers should route through an explicitly selected named configuration so the existing vault boundary remains enforceable.

The Secrets UI should list configured 1Password vaults and provide an Add 1Password vault action instead of switching to only Edit and Disconnect after the first configuration.

Acceptance criteria

• Add, edit, and remove multiple named 1Password configurations without overwriting another configuration.
• Browse provider entries within a specific configured vault.
• Resolve a secret only through its selected configuration and vault boundary.
• Continue redacting service-account tokens and never expose credential values through discovery APIs.
• Migrate an existing singleton 1Password configuration to a default named configuration without breaking existing references.

Current implementation context

The current plugin uses a fixed provider key and stores a single blob under the fixed config key. Its configuration schema contains one vaultId, and configuredVaultUri refuses a fully qualified op:// URI when its vault does not match that configured ID. This request likely needs named provider configurations rather than only an additional vault picker in the UI.

[aarondfrancis]

Suggested implementation prompt for an agent:

Implement issue #1791 in the Executor repository. Read and follow the repository's AGENTS.md before making changes.

Begin by tracing the current 1Password provider end to end, especially:

• packages/plugins/onepassword/src/sdk/types.ts
• packages/plugins/onepassword/src/sdk/plugin.ts
• packages/plugins/onepassword/src/api/group.ts
• packages/plugins/onepassword/src/react/OnePasswordSettings.tsx
• the provider storage/blob APIs and credential-provider item discovery paths

Replace the current singleton, owner-scoped 1Password configuration with support for multiple named configurations per owner. Each configuration must have a stable identifier, display name, authentication metadata, and one vaultId. Add list/create/read/update/delete semantics and update the UI to display all configured vaults with an Add 1Password vault action and per-configuration edit/remove controls.

Design an unambiguous way for provider item discovery and secret resolution to select a named configuration. Preserve strict vault isolation: a reference routed through one configuration must never resolve an item from another configured vault. Discovery must continue returning only opaque identifiers and labels, never secret values. Service-account tokens must remain redacted from every read/UI response.

Maintain backward compatibility. Existing singleton configurations and existing references must continue working after upgrade, either through an explicit migration or a well-tested compatibility path. Do not silently broaden access or require users to recreate working connections.

Before committing to a storage or reference format, identify the compatibility constraints and document the chosen design in the PR description. Prefer the smallest durable data-model change rather than a UI-only workaround.

Add focused tests covering:

• two or more configurations for one owner
• configurations using different vaults and, where supported, different auth methods/accounts
• create, update, and removal without affecting sibling configurations
• item discovery scoped to the selected configuration
• cross-vault resolution rejection
• service-account token redaction
• migration/backward compatibility from the singleton configuration
• the multi-configuration settings UI and its loading/error states

Run formatting, type checking, the affected package tests, and the repository-required e2e scenario. If no existing e2e scenario covers credential-provider settings, add one and provide the recording or trace required by AGENTS.md. Report the final design, migration behavior, tests run, and any remaining compatibility risk.