Add entity sync diagnostics and force-resnapshot tooling

Operators need to tell whether entity sync is waiting, snapshotting, live, retrying, or stalled without reconstructing the answer from runtime and cloud logs. They also need a safe way to replay everything the runtime still retains.

Runtime diagnostics

Add a miren debug cloud-sync command backed by runtime sync state. Report:

• Uplink and capability-negotiation state
• Source-preparation state, including deployment migration and marker backfill
• Source epoch and export-schema digest
• Current mode: waiting, snapshotting, watching, or retrying
• Cloud’s committed cursor and the next watched revision
• Snapshot progress
• Last acknowledgement and last error

Cloud diagnostics

Expose an admin API for the durable receiving state:

• Connection and negotiated-capability state
• Source epoch and schema digest
• Committed watermark
• Pending snapshot ID and progress
• Last successful commit
• Projection quarantine count and recent errors

Revision distance alone must not be presented as entity backlog. Unexported etcd writes also advance the global revision.

Force a full snapshot

Add a cloud-side operation that resets the cluster’s entity-sync state and ends its current uplink session. On reconnect, ordinary capability negotiation requests a complete snapshot. This must require no special reset command or admin endpoint in runtime.

Keep existing landing and projection data available while the replacement snapshot arrives. Historical archive entities that runtime has already pruned remain intact.

A literal purge of cloud landing data and deployment history is outside this issue.

Done when

• The runtime command identifies each normal wait or failure stage.
• Cloud exposes the durable status through an admin API.
• An operator can force a complete snapshot using normal entity-sync protocol behavior.
• Resnapshotting does not blank existing app or deployment views.
• Projection quarantine is visible without searching logs.