get-next-version-code.sh can collide with versionCodes burned by a failed/expired Play edit

Why

scripts/get-next-version-code.sh computes the next Android versionCode as "highest versionCode already committed to a Play Store track, plus one." Google Play permanently reserves a versionCode the moment a bundle is uploaded to any edit, even one that later expires without being committed to a track -- so a failed/expired upload burns a versionCode the script can never see, since it only looks at committed track releases. This caused the 1.6.2 release (2026-09-01) to fail twice: the first run's edit expired after upload (nothing shipped, versionCode 669 got silently burned), and the retry recomputed 669 again and was rejected outright by Play with "Version code 669 has already been used." Confirmed via Play Console that 1.6.1 was still the live production release throughout, so no broken release reached users -- but the release was blocked until worked around.

A one-off floor bump unblocked the immediate release (see PR referenced below). This ticket is the follow-up for the durable fix.

Scope

Make get-next-version-code.sh track its own persisted ratchet (highest versionCode ever attempted, not just published) so a failed/expired upload can never cause a repeated collision.

Acceptance Criteria

• Script's computed "next versionCode" accounts for versionCodes that were uploaded to Play (even via an expired/uncommitted edit), not only ones committed to a track
• The one-off hardcoded floor bump added to unblock 1.6.2 is removed/superseded by the durable mechanism
• Approach documented in the script's header comment (this file already carries detailed rationale comments for prior fixes -- follow that convention)

Out of Scope

• Re-litigating the choice of r0adkll/upload-google-play or the overall release pipeline shape
• The general Play Console permissions gap (Troy's account lacking halt/edit permission on production releases) -- not yet tracked, separate concern

Links

• Related to the 1.6.2 release (2026-09-01)

Start with scripts/get-next-version-code.sh and read its header comments and current versionCode lookup. Trace where the one-off floor bump is applied and how the script determines the highest committed Play track version. Done means the script persists and advances the highest attempted versionCode, removes or supersedes the temporary floor, and documents the approach in the header.