fix: stop attributing the sqv rejection to the key algorithm

Refs #1.

`scripts/install-apt.sh` explained the sqv rejection as a malformed MPI
encoding in an Ed25519 key. The registry does not serve one: at
`api/packages/heavy-duty/debian/repository.key`, `gpg --list-packets`
reports `algo 1` (RSA) with a 2048-bit `pkey[0]`. The explanation was
therefore wrong about the only part of itself that was checkable.

The comment now states the measurement and points at #1 for the cause,
rather than naming a mechanism nobody verified. This satisfies #1's
criterion that `git grep -in 25519` return no hits outside test fixtures,
which it now does.

Behaviour is unchanged: this commit edits a comment. The automatic
fallback this file still performs contradicts ruling B and is NOT fixed
here — that work is still owed on !38.

scripts/install-apt.sh

@@ -123,9 +123,11 @@ if [ "$($SUDO curl "${CURL_AUTH[@]}" -sSL -o /dev/null -w '%{http_code}' "$RELEA
 fi
 
 # Newer apt verifies with sqv (Sequoia), which rejects the signature Forgejo
-# currently produces for its Debian registry (malformed Ed25519 MPI encoding
-# in the upstream signing library). Try the properly signed source first so
-# this heals automatically once the forge is fixed. Only that signature-error
+# currently produces for its Debian registry. The cause is recorded on #1; it
+# is not the key algorithm, because the registry serves an RSA-2048 signing
+# key (`gpg --list-packets` on repository.key reports `algo 1` with a
+# 2048-bit pkey[0]). Try the properly signed source first so this heals
+# automatically once the forge is fixed. Only that signature-error
 # class permits the compatibility fallback; auth, network, and other failures
 # must leave verification enabled and retain apt's original diagnostic.
 if update_output="$(update_only_source "$LIST" 2>&1)"; then