fix(ci): let a build-only bump ship, and gate publishing separately

Reworks the gate this branch added. The first version answered one
question — does `v<version-name>` already exist — and gated all five
deploy jobs on it. That refuses a build-only bump: 2.2.0+63 to 2.2.0+64
is a new binary under an existing version name, and both derive
`v2.2.0`. A build-only bump is a legitimate TestFlight release and must
ship.

Two questions were being conflated, with different ledgers and different
stakes:

  deploy  — is there a NEW BUILD for the stores? Keyed on the build
            number. Read by the four packaging and deploy jobs. Getting
            it wrong costs a red run and two store rejections.
  publish — is `v<version-name>` still unclaimed? Keyed on that tag.
            Read by `github-release` alone, because that is the only
            destructive path: on an existing tag the action does not
            fail, it updates in place, and `overwrite_files` defaults to
            true, so it would delete the published IPA, AAB and APK and
            re-upload binaries from another commit. Permanent — GitHub
            does not version release assets.

The build ledger is a `deployed/<n>` tag pushed by both deploy jobs on
success. Keyed on the build number alone: a Play versionCode is spent
forever regardless of which version name carried it, and a
version-qualified key would wave through the commonest slip — bumping
the name and forgetting the build.

The ledger starts empty, so it carries a hardcoded floor,
LAST_BUILD_BEFORE_LEDGER=63, rather than a tag seeded by hand. A
pre-merge step done exactly once is the step that gets forgotten, and
`release-gate` has no `needs:` — it reaches the question thirty seconds
into the run, so there is no window to win afterwards. Without the floor
the very first run reads build 63 as new and re-pushes it to both
stores, which now fails on Play as well since 63 was uploaded by hand.

The floor also catches what a marker ledger cannot: build numbers are
not monotonic here. 1.3.1+51 and 1.4.0+51 both used versionCode 51, and
1.4.0+51 follows 1.3.2+55.

Unreachable remote, malformed version, non-integer build number, or a
name bumped with the build forgotten all fail the job loudly rather than
guessing. No `needs:` entry changes anywhere.

The runbook is updated in the same change, because this alters what a
releaser has to know and a stale runbook is what nearly ran 2.2.0.

Verified against the real remote: 2.2.0+63 gives deploy=false
publish=false and a green run — which is exactly what this PR's own
merge commit is; 2.2.0+64 ships to both stores without touching the
v2.2.0 release; 2.3.0+64 does both; 2.3.0+63, 2.2.0+abc and an
unreachable remote exit 1; 1.4.0+51 is caught by the floor. Outcome
matrix passes and actionlint reports no new findings.

Refs #1011, #1012

Author: simonoppowa