fix(sync): damp unproductive exact VM reconcile batches

[branarakic]

Summary

• add bounded, process-local exponential backoff for identical exact VM-reconcile target batches that reached peers but made no verified progress
• scope the delay to the exact target set and connected-peer topology so new work and newly available sources retry immediately
• clear the delay immediately after verified reconciled / already progress and avoid consuming it when no peer fetch was attempted
• prune and clean up the new state with the existing reconciliation caches

Why

Testnet publisher evidence showed the same verified-vm-metadata-pending or empty private-graph batches being fetched from multiple peers every 60 seconds without any verified state transition. Some cycles inserted thousands of triples but could not repair missing provenance, so they consumed global sync capacity without advancing VM convergence.

This PR does not synthesize provenance, relax verification, or mark pending content confirmed. It only spaces repeated network work after a batch has proved unproductive.

Retry semantics

• first identical unproductive batch: approximately 1 minute (deterministic jitter)
• subsequent failures: exponential delay up to the existing 10-minute cap
• new exact target set: immediate
• connected-peer topology change: immediate
• verified progress: immediate next slice
• no attempted peer fetch: no backoff growth
• process restart: state resets and fails open

Validation

• agent dependency/build chain: passed (tsc, test:types, test:package-root)
• focused reconciliation suite: 68/68 passed
• full agent unit lane: 139 files, 1,789 passed, 5 skipped, 0 failed
• git diff --check: passed

Rollout boundary

Draft PR targeting testnet-canary. It has not been merged or deployed. Distributed completeness validation remains pending until the second edge receiver returns; its last checkpoint is preserved and no manual catch-up was triggered.