ci: bump codecov-action to v7.0.0 to fix GPG verification failure

[darkobas2]

Problem

The Coverage Report job has failed on every master run since at least 2026-07-21, always at Upload coverage to Codecov:

gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
gpg: Can't check signature: No public key
==> Could not verify signature. Please contact Codecov if problem continues

Cause

The wrapper imports Codecov's signing key before verifying the CLI binary, and that import brings in zero keys — so the check that follows has nothing to verify against. The signature itself is genuine (RSA key 27034E7FDB850E0BBC2C62FF806BB28AED779869).

We are pinned to 671740a = v5.5.2, whose wrapper fetches from keybase.io/codecovsecurity/pgp_keys.asc. Codecov deleted that keybase account and moved to codecovsecops — see the v7.0.0 release notes. So the fetch returns nothing every time. This is permanent, not a transient keyserver blip, which is why it has been red for over a month.

Tag	Key source	Works
v5.5.2 (current pin)	codecovsecurity — deleted	no
v5.5.5 / v6.0.2 / v7.0.0	codecovsecops	yes

Fix

Repin to fb8b358 = v7.0.0. Like v5 it is a composite action, and the three inputs used here (token, fail_ci_if_error, files) are unchanged, so it is a drop-in swap. v5.5.5 would also work, but v7 is current and avoids a second bump.

Side effect worth noting

trigger-beekeeper declares needs: [test, lint, coverage], so it has been skipped on master for over a month along with the coverage job. Merging this should restore it.

Verified: coverage upload is the sole failing step in runs 31598773732, 31309568489, 30883431856, 30010913210 and others.

[darkobas2]

Note for reviewers: this PR cannot demonstrate the fix in its own CI. The coverage job is gated on if: github.ref == 'refs/heads/master', so it shows as skipped here and will only be exercised after merge.

Direct evidence instead — fetching the two key URLs the wrapper uses:

Keybase account	Used by	Result
codecovsecurity	v5.5.2 (current pin)	HTTP 404, no key returned
codecovsecops	v7.0.0 (this PR)	HTTP 200, valid key 27034E7FDB850E0BBC2C62FF806BB28AED779869

That fingerprint is the same key the failing logs report as having signed the binary:

gpg: Signature made Thu Jul  9 01:37:57 2026 UTC
gpg:                using RSA key 27034E7FDB850E0BBC2C62FF806BB28AED779869
gpg: Can't check signature: No public key

So the signature was always valid and verifiable; the old pin was simply fetching the public key from a URL that no longer exists.