Gate Maple provider admission on model health after attestation #1483

During a dedicated Maple model restart, attestation succeeded before the model's /health endpoint became healthy. OpenSecret admitted the provider while the model was still warming. An Auto:Quick Responses first turn received an upstream 503 and returned logical 503 inference_capacity without a successful alternate-provider attempt.

The replay protection classified the attempt as AwaitingResponse / NotProvenPreAcceptance and preserved its existing conservative behavior. Admission needs the additional health check.

Verified against deployed source ac6f43b3815995cdd871531b0c8eb4f9cdc8c79e:

• MapleReadiness returns transport.snapshot().is_ok(). The snapshot establishes verified transport, without checking model-serving health.
• Responses error handling preserves the non-replayable upstream error.
• Capacity cooldown protects later attempts; it does not recover this logical request.

Proposed correction: in Maple's common client-creation path, verify attestation first, then make a bounded, body-free GET /health through that same pinned transport, using existing provider authentication. Publish the client as eligible only after health succeeds. Apply this to startup and TLS refresh, reusing background recovery. Preserve the SDK protocol, approved measurements, and Responses replay rules.

Regression coverage should establish:

• Successful attestation plus health 503 or timeout leaves Maple ineligible, allowing an existing eligible stock provider to be selected before inference is sent.
• Health 200 admits the attested instance; failed attestation remains ineligible regardless of health.
• TLS refresh repeats health qualification before promotion.
• Health recovery performs no generation or completion replay.

Once model startup completed, direct authenticated normal and streaming inference passed. This issue tracks the startup admission gap; implementation and deployment are follow-up work.