A live probe (archlinux:latest in podman against a production instance,
TLS via the environment root CA) showed both documented client recipes
fail on real clients:

- pacman: `pacman-key --add` alone leaves the key at "unknown trust" —
  `pacman-key --lsign-key <fingerprint>` is mandatory; and the Arch canon
  `SigLevel = Required DatabaseOptional` demands package signatures, so
  pacman fetches `<pkg>.pkg.tar.zst.sig` (404) and aborts with "failed to
  commit transaction". Working recipe: `SigLevel = Never DatabaseRequired`
  (the database signature is verified with the instance key; packages in
  personal repositories are not signed by design).
- rpm-md: `gpgcheck=1` verifies the `.rpm` signatures themselves, which
  the generator never writes; use `repo_gpgcheck=1` +
  `gpgkey=<base>/key.asc` + `gpgcheck=0`.

Also documented: after an instance key change the published indexes stay
signed with the previous key while `/repo/<name>/key.asc` already serves
the new one — the client reports `key "<fpr>" is unknown` and goes to an
external keyserver (absent in a sovereign environment); the cure is a
reindex. Diagnosis: `gpg --list-packets <repo>.db.sig` (issuer fpr)
versus `gpg --show-keys key.asc`.

Touched: func/{ru,EN}/{ecosystems/pacman,ecosystems/rpm-md,personal-repos},
RELEASE.md checklist, TESTING.md (live-probe case), CHANGELOG ru/EN.