## Why

Generic `sk-...` credentials can match several supported providers, while the current exact-hint routing leaves ambiguous findings unconsumed and can eventually quarantine them without testing a compatible provider. The keycheck pipeline needs ordered provider resolution and ZAI coverage so a credential is attributed to the first provider that positively recognizes it.

## What Changes

- Add durable, sequential resolution for credentials whose format or finding context permits multiple providers.
- Distinguish provider mismatch from authenticated match and retryable probe failure.
- Stop remaining provider attempts after the first positive match while retaining auditable attempt outcomes.
- Add a ZAI provider checker with a minimal generation/billing probe and include ZAI in compatible generic-key routing.
- Keep explicit single-provider findings on their existing direct validation path.

## Capabilities

### New Capabilities
- `ambiguous-provider-resolution`: Ordered, durable validation of one ambiguous credential across compatible providers until one positively matches or all definitive routes are exhausted.
- `zai-key-validation`: Extraction, probing, classification, persistence, and runtime registration for ZAI API credentials.

### Modified Capabilities

None.

## Impact

- Affects scanner provider hints, keycheck candidate extraction, PostgreSQL queue/schema operations, provider checker orchestration, status projection, runtime configuration, and lifecycle authority manifests.
- Adds a ZAI checker module using the existing HTTP and PostgreSQL keycheck infrastructure; model-list authentication alone does not qualify a key as alive.
- Requires regression coverage for route ordering, retry behavior, atomic match resolution, candidate deduplication, and ZAI response classification; the existing free-form service and credential tables require no schema migration.