bash-3.2 CI gate is externally flaky: vendor Chet Ramey's signing key instead of fetching from keyservers #395

Problem

The acq offline suite under bash 3.2 job builds bash 3.2.57 from source and verifies the tarball against Chet Ramey's GPG key, which it imports from public keyservers at job time. When the keyservers are unavailable the job fails closed in the setup step — before any test runs — and red-flags an otherwise healthy PR:

##[error]could not import bash signing key 7C0135FB088AAF6C66C650B9BB5869F064EA74AB from any keyserver

Observed on #390 (cleared on re-run). This is the second external-fetch flake to red-flag a healthy PR in two days (the other was a gnu.org link-check timeout), so the cost is recurring: a maintainer has to recognize the failure isn't theirs and re-run.

Fix

Vendor the ASCII-armored public key in-repo and import from the file instead of a keyserver. The trust anchor is unchanged — today's security comes from the workflow hardcoding the full 40-hex fingerprint and verifying the imported key matches it, so the keyserver is already treated as untrusted transport. Committing the key removes the availability dependency without weakening anything:

• keep the hardcoded fingerprint check against the vendored key (so a bad commit to the key file still fails closed);
• keep gpg --verify of the detached signature;
• drop the 3-keyserver retry loop.

Why this is reliability, not security

A substituted key already fails the fingerprint comparison, so keyserver availability buys no integrity — only failure modes. This was raised as a non-blocking note during the review of #332 (which introduced the gate); filing it properly now that it has blocked a second PR.

AI-assisted (OpenCode).