#3557 typed-secrets 2.1: VaultExistenceProvider, its conformance suite, and has on the built-in providers

Outcome

A vault provider can answer whether get(key) would succeed without reading the value, and a conformance suite in packages/testing/ holds every provider that claims to. Nothing calls it yet, so no run-time behavior changes.

Why now

Phase 2.3 stops the eager vault read and replaces it with the existence check in design/enablers/typed-secrets.md Section 3.4. A provider without has then costs one probe read per reference per run, which matters where a read has an effect, such as minting a dynamic credential. Shipping the contract first lets the built-in providers implement it before the check goes live, and lets extension authors do the same from the release notes (Section 10.3).

This is the first of three Phase 2 issues (Section 11). 2.2 makes bag entries hold references; 2.3 loads at delivery and runs the check. 2.1 depends on neither.

Scope

• The optional VaultExistenceProvider.has(key) contract in src/domain/vaults/. Its contract is that get(key) would succeed under the same provider credentials. Presence in a listing or a describe call is not enough.
• A conformance suite in packages/testing/, following datastore_conformance.ts, that holds a provider to that contract: has is true exactly when get succeeds, false for a missing key, and an authorization failure surfaces as the same error get raises. The suite proves with a counting store that a has answer never reads a value.
• has on each built-in provider whose API can answer without reading the value, and none where it cannot. Each decision is recorded in the provider with the reason.
• VaultService exposes the capability, so a caller can tell a has answer from a probe read.
• A test vault provider in packages/testing/ that counts get and has calls separately. 2.3's exit (one load per reference per attempt, at most one probe per reference per run, no value read for a key has confirms) is measured with it.

Follow the repository conventions: unit tests beside the source, the conformance suite in packages/testing/, no subprocesses or env mutation, and deno run license-headers for new files.

Exit

• Every first-party provider passes the suite, or does not implement has.
• A has answer never reads a value, proven by the counting store.
• The counting test provider exists and is exercised by the suite.
• No run-time behavior changes; existing suites pass unchanged.

Out of scope

• Calling has from the evaluator, the probe read, and the existence check itself (2.3).
• Any change to sentinels, bags or the persisted form (2.2).
• Remote providers over the data plane (Phase 5).