Investigate: order may stall if DCV starts late; sync-DCV retry may not rescue it #35

Scope

DCV-enabled builds only (SUPPORTS_DCV, v2.x). No impact on v1.x / non-DCV builds. This is an investigation, not a confirmed defect: the evidence is two orders observed during a validity probe.

Observation

While running the PR #20 validity probes (V1 API, sandbox DV product 842), two raw orders had DCV attempted late (probably more than ~10 s after placement, because the harness did other work first). Both stalled at "Pending System RA" with caaStatus=2, and GetDcv answered "Invalid Request for this API." for at least 4 minutes of polling. The same order body with DCV run immediately after placement issued in about 1 minute.

Why it might matter

CLAUDE.md describes the sync-DCV retry (TryRunDcvDuringSyncAsync, via Synchronize(fullSync:true) / GetSingleRecord) as the way to complete pending DV orders. If CERTInext only accepts DCV within a short window after placement (or after a state transition), an order that misses the in-call DCV may not be recoverable by the retry path, and would sit pending until it is cancelled and re-ordered.

Caveats

• Cause is inferred from two orders; the wait was only about 4 minutes; the orders were placed by a test harness, not through the plugin's Enroll.
• Not reproduced through TryRunDcvDuringSyncAsync.

Suggested work

1. Reproduce through the plugin: place a DV order with DCV disabled, wait several minutes, then run GetSingleRecord / Synchronize with DCV enabled, and record whether the order issues.
2. If it does not, find out what CERTInext requires (ask support; add to the support-questions file) and decide whether the retry path needs to cancel and re-place, or surface a clear log message.