chore: sign Linux repositories only with the new PGP key - #14197

Description

We are rotating the PGP key used to sign our Linux package repositories. The old/current key (K1, 2C6106201985B60E6C7AC87323F3D4EA75716059) is expiring, and we have already introduced a new key (K2, 7F38BBB59D064DBCB3D84D725612B36462313325).

In Step 1 (#13271, merged) we started signing the APT repository with both keys so existing and new users would keep working across the transition. This PR is Step 2: after the old key expires, we drop every reference to K1 and sign the APT repo, the RPM repo, and the individual .rpm files with K2 only.

Concretely:

• script/distributions: every SignWith line now lists only K2 (was K1 + K2).
• script/rpmmacros: %_gpg_name now points at K2 (was K1), so .rpm package signing uses the new key.
• .github/workflows/deployment.yml, "Set up GPG": removed the K1 secrets and import/preset steps, keeping only the K2 (_2026) secrets.
• .github/workflows/deployment.yml, "Run createrepo": the --default-key used to sign repomd.xml now points at K2.

How did you test this change?

This is a deployment-workflow and packaging-config change; it cannot be exercised via the gh CLI locally. Verification is done after a release is cut, per the tracking issue:

Given a new release has been published
When I run the checks below
Then each repository/artifact is signed only with K2 (7F38BBB59D064DBCB3D84D725612B36462313325):

# APT repo metadata: one signature, K2 fingerprint
curl -o - https://cli.github.com/packages/dists/stable/Release.gpg | gpg --list-packets

# RPM repo metadata: one signature, K2 fingerprint
curl -o - https://cli.github.com/packages/rpm/repodata/repomd.xml.asc | gpg --list-packets

# RPM package: signed with K2 (last 16 chars of the fingerprint)
curl -o test.rpm 'https://cli.github.com/packages/rpm/gh_2.X.X_linux_amd64.rpm'
rpm -qipv test.rpm

The published keyring (githubcli-archive-keyring.gpg/.asc) contains both keys, so clients that trust K2 will validate the new signatures.

Key points

• Timing is the critical constraint: this must land only after K1 expires and before the next release is cut. Doing it earlier would sign packages with a key that some clients do not yet trust as the sole signer. Hence the warning banner above.
• We are intentionally not removing the expired key from the public keyring. Users who verify older releases (RPMs carry an embedded K1 signature tag) still need it, and keeping expired keys in a keyring is common practice.

Notes for reviewers

• Start with .github/workflows/deployment.yml ("Set up GPG" and "Run createrepo"), then script/rpmmacros and script/distributions.

Authorship and follow-up

Who wrote this:

• A human wrote it.
• An agent wrote it under close human direction.
• An agent wrote it independently, and no human has guided the implementation beyond the initial prompt.

Who answers review comments:

• @babakks will read and reply directly.
• An agent will draft replies and @username will read them before they are posted.
• Nobody has explicitly committed to replying.