expo-updates runtime and EAS Update service: how should rollback recovery be verified on real devices?

Context

Our app ships with the expo-updates runtime embedded in the binary and receives OTA bundles from the EAS Update service via channel/branch mapping. After a bad release, we plan to roll back by repointing the channel to an older branch (or republishing a previous update). The interoperability gap is at the trust boundary: the client decides which published update to apply based on runtime version policy, its check cycle, and (if enabled) code signing, none of which the server can force.

Uncertainty

Because propagation depends on app relaunch and the configured check behavior, a rollback is not instantaneous, and a runtime version mismatch makes the client silently keep the embedded bundle. That means "we rolled back" on the server side does not equal "devices recovered." We need a verification strategy that works across a fleet, and we are unsure whether to trust client-side telemetry (logging Updates.updateId and Updates.channel at launch) or EAS dashboard insights, since neither alone seems to guarantee every device reverted.

Questions

1. For confirming recovery after a channel rollback, is logging Updates.updateId at launch from each device the accepted source of truth, or can EAS Update insights be relied on for fleet-wide confirmation?

2. When code signing is enabled, what is the expected client behavior on a wrongly signed rollback update: silent fallback to the embedded bundle, or a surfaced error we can detect?

3. Is there a documented way to shorten or force the check cycle for recovery-critical rollbacks, given that OTA cannot fix native-binary crashes anyway?