Real-world integration test: 1Password

[smiggleworth]

Why

Every test for internal/onepassword runs against a hand-written fake implementing API/LookupAPI/MutationAPI. Nothing in this package has ever talked to the real 1Password service. This is the oldest provider in the codebase and has had the most review passes, but "reviewed carefully" and "run against the real SDK" are still two different bars.

What to verify against a real 1Password account

Write path (Adapter.WriteMany)

• Version-conflict retry: confirm the real SDK's write-conflict error actually implements the unexported-shape interface{ VersionConflict() bool } this code type-asserts against (versionConflict in write.go) — this is checked via errors.As, so it depends on the concrete error type the SDK returns matching that method set, which has only ever been simulated in the fake.
• Confirm the retry actually resolves under genuine concurrent writers touching the same item.
• Field/section matching by ID-or-Title, and the Ambiguous error path, against a real item that has genuinely duplicate field or section titles (not just the fake's synthetic setup).
• Category != op.ItemCategorySecureNote rejection against a real non-Secure-Note item.

Read path (Adapter.ReadMany)

• Confirm reading a concealed field vs. a non-concealed field with the same title behaves as the code assumes (only concealed fields are matched).
• Nested section paths (section/field key syntax) against real multi-section items.

Caching (listVaults/listItems)

• These are cached for the adapter's lifetime with no invalidation. Confirm this doesn't cause a real problem within a single uno sync run — e.g. a template that both creates a new item in a vault and then, in a later mapping in the same run, expects to find that item — since the cache would still reflect the pre-creation vault listing.

Auth

• OP_SERVICE_ACCOUNT_TOKEN and OP_ACCOUNT (desktop integration) code paths both actually authenticate against the real service, not just construct a client without erroring.

Scope

Needs a real (disposable) 1Password account/vault, ideally tested with both a service account token and desktop-app integration to cover both auth paths.