A production release can go to a percentage of users first, chosen at random for each release, but only for updates: an app's first release reaches everyone. The percentage never rises by itself; you raise it under Manage rollout > Update rollout; halting the rollout stops new users from receiving the version (those who have it keep it) until you resume it. These steps, from the Play Console 1 Help, were not run here.
Three things differ from a web deployment, which you can simply revert:
Every fix needs a higher versionCode. A halted 1.0.1 (10001) cannot be replaced by a rebuilt 1.0.1; the fix ships as 1.0.2 (10002), and Play rejects any upload that reuses a number.
Crash reports arrive readable. Android vitals in the Play Console deobfuscates stack traces with the proguard.map the bundle carries (Building an Android App Bundle), so the vb1.p frames of R8 Full Mode appear as Diagnostics.testCrash without a manual upload.
Priority belongs to the release. The updatePriority() that BookNest's update rule reads (In-App Updates) can be set only through the Play Developer API when the release is created, as inAppUpdatePriority from 0 to 5, and never changed afterwards. Gradle Play Publisher 4,319 exposes it with updatePriority.set(5) next to userFraction.set(0.1) and releaseStatus.set(ReleaseStatus.IN_PROGRESS).
A cautious schedule is 1% for a day, then 10%, 50% and 100%, comparing the new version's crash and ANR rates with the previous one's before each step. Archive every release's bundle and mapping.txt.