test(v2): 0090 place-order latency experiment and sandbox order cleanup

[spbsoluble]

Test-only change for issue 0090 (enroll/sync race: duplicate key on the gateway's enroll save). Stacked on #30. No product code changes.

What this adds

• V2PlaceOrderLatencyExperimentTests (opt-in, CERTINEXT_V2_LATENCY_EXPERIMENT=1): runs the plugin's real V2 Enroll through a timing proxy over ICERTInextClient, with a parallel /reports/orders poller and a Track Order poller, to measure how long the CA call stays open and when a concurrent sync can see the order.
• V2OrderCleanupTests (opt-in, CERTINEXT_V2_CLEANUP_ORDERS=<ids>): revokes or cancels explicitly listed sandbox orders only (digits-only IDs, max 25, optional dry run, no pattern matching, no sync).
• Fixture opt-in flags for both, and experiment-results/ (5 CSVs + a summary) from 13 sandbox orders.

Findings (sandbox, 13 orders; suggestive for production, not proof)

• V2 place-order takes ~4 s. The hold is on PUT /csr: 17-23 s (median 20 s) while the order is already issued. Total Enroll 25-30 s.
• The order is listed in /reports/orders ~1.5 s after create, as "Approved by System" with no certificate, for ~20-25 s before Enroll returns the CARequestID. A sync pass in that window inserts a body-less row and the enrollment's save then fails.
• Lab repro on this branch's base (V2, no-DCV build on the 25.5.0 lab gateway): 4 of 4 saves failed with duplicate key on UQ_Certificates_CertificateAuthorityID_CARequestID. A fifth enrollment failed separately on a CERTInext 500 on place-order that still created an order.
• The gateway upsert on (CA, CARequestID) remains the real fix; nothing here changes plugin behaviour.

Test plan

• Release build: 0 warnings.
• New tests skip cleanly without their env flags; existing fixture and guard tests pass.
• Live runs: sandbox only (fake credits). All 13 + 6 test orders were revoked or cancelled.

Draft until reviewed.