Reduce redundant USDT recovery exports without losing pending state #1157

Review follow-up from #1118, head e5aa577, with Android parity in #1681.

Observers can schedule a fresh whole-history export after a required callback upload, and restoration reads retained immutable records. The source confirms potential write amplification; the review's 50/500-transfer size and timing estimates are not author-verified measurements.

The callback acknowledges the exact supplied Core snapshot. It must not mark a newer ordinary-backup requirement synced merely because the required revision was unchanged during that upload: the requirement may already describe state newer than the supplied bytes. Identical content-addressed PUTs reuse the same key; extra requests alone do not establish extra retained records.

Investigate coalescing using proven Core and association content/revision coverage. Preserve acknowledgement before broadcast, the original signed operation, pending work after failures/concurrent changes, incoming transfer state, and meaningful changes beyond transfer ID/status. Do not prune acknowledged records or change complete-WALLET compatibility without a separate safe protocol.

Acceptance: measure requests, unique keys, bytes and restore latency separately on controlled histories; show failure/concurrent-update cases retain every required snapshot and operation; verify both apps' restore union. No production funds, existing-wallet reset or broad retention redesign is needed for this investigation.

This is deferred LOW performance work from the current 3.1.0 PR to 3.2.0, not a reproduced loss of recovery correctness. Review timing/size extrapolations have not been independently benchmarked.