perf(resolve): query base and override secret stores concurrently

[harrisoncramer]

When a project layers a secret override over a base store, each app resolves its secrets from both, and today the layered resolver does them one after the other: it fully resolves the base, then resolves the override, then merges. Each of those is an independent round-trip to a store, so for two 1Password vaults an app pays base latency plus override latency in series even though neither depends on the other.

This runs the two queries concurrently and joins the results, so an app pays the slower of the two rather than the sum. The merge semantics are unchanged: an override value still wins over the base, a base failure is still fatal, and an override that reports ErrSecretNotFound still means it does not cover this app and falls through to the base. That last case is handled inside the override goroutine so it neither fails the group nor cancels the base query that is still in flight.

Note on ordering: on its own against main this is a structural change with little wall-clock effect, because the 1Password resolver currently serializes every op invocation behind a global mutex, so the two concurrent queries still run one at a time. It pays off once that serialization is lifted (the warm-session-then-parallel change on the other branch), at which point base and override overlap and per-app resolution drops from base+override to max(base, override). Kept on a separate branch off main so the two approaches can be compared independently.

[harrisoncramer]

AI-GENERATED: Closing. Benchmarked stacked on the warm-session change: concurrent base+override is ~2s slower, not faster. op has no real internal parallelism and interleaving two vaults thrashes its per-vault session cache, so the serial base-then-override layering (which groups calls by vault) wins.