Incremental sync refetches every issued/revoked order of the UTC day on every pass (TrackOrder + download per row) #36

Scope

V1 sync path (release-1.0 line, CERTInextCAPlugin.Synchronize). Not a regression from the issue-0090 hold-back (PR #20); found while live-testing it. Proposed for 1.0.2, not 1.0.1.

Symptom

Every incremental pass re-lists every order created on the UTC day of issuedAfter and, for each issued or revoked row, calls GetCertificateAsync (TrackOrder plus a certificate download), then emits the record to the gateway again. Revoked rows are re-emitted on every pass until the day rolls over.

Cause

• The order-report listing never carries the certificate body, and the incremental listing is day-granular (orderDateFrom is the UTC date of issuedAfter).
• Synchronize refetches the full certificate for any issued or revoked row whose listing entry has no body (CERTInextCAPlugin.cs:997-1028), so Command always gets a body.
• The refetch is deliberate: Command cannot store a body-less record, and a body-less REVOKED row for an order the gateway holds no certificate for makes every Command scan of the CA fail (issue 0049). So the rows cannot simply be emitted without a body or skipped.

Evidence

• Sandbox live run of SyncHoldBackLiveTests (branch test/0090-live-hold-back, b6da49d): every incremental pass re-emitted the earlier revoked sandbox orders (Revoked=1 or 2 in the sync summary) and made a TrackOrder call per revoked row. The test needs a preflight cap (400 rows listed today) because each pass refetches every issued row.
• Cost per pass is about 2 API calls x (issued + revoked orders created that UTC day). Illustration only, not measured: at a 10-minute incremental cadence (144 passes/day) and 50 orders/day, about 14,000 calls/day.

Design notes

• Issued rows: skip the refetch and the emit when the gateway already holds the body. ICertificateDataReader.GetExpirationDateByRequestId already exists for this (used at CERTInextCAPlugin.cs:1451): a date means a body is held, null means a row with no body, ArgumentException means no row. An issued row whose status has not changed needs no update.
• Revoked rows are harder. A body-less REVOKED emit is safe for a row the gateway already holds with a certificate, but the revocation date and reason come from TrackOrder (MapToAnyCAPluginCertificate, RevocationDate = cert.RevokedAt), so skipping the refetch loses them. The reader also cannot tell whether the gateway already recorded the revocation.
• Possible approach: an in-process cache of "already emitted this status for this order", used by incremental passes only. Full syncs always bypass it, and a pod restart re-emits once. Trade-off: if an earlier emit was lost, the row stays stale until the next full sync.
• Any change here touches the emit path next to the issue 0049 poison-row problem, so it needs unit tests plus a kfclab run (Command scan after a revoked row is skipped) before release.

Not in scope

Incremental listing missing orders revoked on a later day (listing filters by order date) is a separate, known incremental-scan gap.