fix: stop stable index clobber on BE publish + dearmor key in docs

[bpamiri]

Fixes the install-blocking half of wheels-dev/wheels#2838. This is the live counterpart to wheels-dev/wheels#2846 (which patches the in-repo template copy of these files).

Bug

apt install wheels returns "Unable to locate package wheels" even though the stable .deb is in the pool — because the stable Packages index at apt.wheels.dev/dists/stable/main/binary-amd64/Packages is 0 bytes:

Channel	.deb in pool	Packages index
stable	✅ wheels_4.0.2_amd64.deb (80 MB, HTTP 200)	❌ 0 bytes
bleeding-edge	✅	✅ populated

Root cause: regenerate-apt-metadata.sh loops over both channels every run, but the workflow only syncs/slots the dispatched channel's pool into the runner. On a bleeding-edge publish (which fires on every develop merge) the stable iteration scans an empty local pool/stable/, emits an empty Packages, and the upload step's unscoped find dists -type f pushes it to R2 — clobbering the good stable index. The stable InRelease is timestamped identically to the latest BE run and lists the empty-string hash for Packages, confirming this.

Fix

• regenerate-apt-metadata.sh honors a CHANNELS env (defaults to both for manual full-tree repair); the workflow passes the single dispatched channel, so a run only rebuilds the dist whose pool it synced.
• The dists upload is scoped to dists/${CHANNEL}/ (defense-in-depth).
• The landing page (index.html) and README.md install snippets pipe the ASCII-armored key through sudo gpg --dearmor before writing /usr/share/keyrings/wheels.gpg — modern apt rejects an armored key in a signed-by= keyring.

Verified with a stubbed-apt-ftparchive harness: the current script emits an empty dists/stable/Packages on a bleeding-edge run; with CHANNELS=bleeding-edge it emits none and leaves the stable index untouched, while bleeding-edge still indexes correctly.

After merge — rebuild the empty stable index

R2's stable index is already empty and won't self-heal. Trigger a one-off stable re-publish (uses the existing .deb in the pool):

gh workflow run wheels-released.yml --repo wheels-dev/apt-wheels -f version=4.0.2 -f channel=stable

Then confirm https://apt.wheels.dev/dists/stable/main/binary-amd64/Packages is non-empty and sudo apt update && sudo apt install wheels works on a clean Debian/Ubuntu host.

Note: this PR is scoped to the #2838 fix. The workflow here has otherwise drifted behind the wheels-repo template (it predates the R2 list-API success==true guard and the process-substitution hardening); syncing those is a worthwhile follow-up but intentionally out of scope.

🤖 Generated with Claude Code