🐛 hub: cache stable-promotion status and use authenticated GitHub reads

[hivecommons-hive]

What

• stablePromotionFetchRuns builds the workflow-runs request with http.NewRequest against githubAPIBase and passes it through authGitHubRequest, like every other hub GitHub read.
• New ttlFlight keyed cache (stable_promotion_cache.go) with single-flight refresh: concurrent callers for one key share a single fetch; failed refreshes are not cached and the previous answer is served within channelRevisionStaleGrace (same contract as channelRevisionSHA).
• Cached for channelDigestTTL (5 min): the docker.yml runs list, per-run GHCR verification (digest + generation, negative results cached too), and ghcrTagGeneration per (repo, tag).
• stablePromotionEligibleBuild tries soaked runs newest-first, then unsoaked runs soonest-eligible-first, stopping at the first verified build, and verifies at most stablePromotionMaxVerifiedRuns = 8 runs per evaluation. Result semantics are unchanged.
• /api/saas/my-hives reuses the status already attached to the stable channel row instead of computing it a second time.
• stableNextPromotionAt is untouched (it picks up the caching through the helpers it calls).

Tests

New stable_promotion_cache_test.go: runs cached until TTL then refetched; 16 concurrent callers → one fetch; failed refresh serves previous answer and is retried; ghcrTagGeneration cached per tag and refetched after expiry; verification capped and reused across evaluations; workflow-runs request carries the hub token. Existing stable-promotion tests reset the caches.

Closes #10605

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88

[kubestellar-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign clubanderson for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[hivecommons-hive]

hive/awaiting-ci: CI pending — sweep will merge when green.

---

🐝 Hive Agent: scanner | Instance: hosted-available-oke-11-placeholder-r05x | SHA: unknown

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88

[github-actions]

Changelog: this PR changes code but carries no changelog entry
(no changelog.d/ fragment and no CHANGELOG.md edit).

If it is user-visible — a feature, a fix an operator would notice, a
security change, a migration, a deprecation, or anything breaking —
please add a fragment file changelog.d/<category>-<pr-or-slug>.md
containing exactly your entry (see changelog.d/README.md; the
category is one of added/changed/deprecated/fixed/security). Please
do not append to CHANGELOG.md's ## Unreleased directly — that
shared section is the merge-conflict generator fragments replaced
(#5675). If it is a refactor, a test-only change, or dependency
churn, no entry is needed and you can ignore this.

This is a reminder, not a gate; it never blocks a merge.

[github-actions]

Open PR overlap check

Base branch: v5

Conflicts are checked with every PR merged onto the current tip of v5, so a PR that only needs a rebase is not reported as conflicting with its siblings.

No conflicting open PRs or same-file overlaps were found.

[hivecommons-hive]

CI red on 17558fe was inherited from the base, not this PR: feedback.go (dashboard:80, hub:378) compiled a (?= lookahead at package init, panicking every hub/rest/dashboard shard, the docker smoke test, overlayfs-exec-guard and golangci-lint; the api-reference citation drift was likewise base-side. Both were fixed on v5 by #10612. Merged origin/v5 into this branch (b5efc2e) — no changes to the PR's own files. Locally go build ./... and check-api-reference-citations.sh pass.

---

🐝 Hive Agent: scanner | Instance: hosted-available-oke-11-placeholder-r05x | SHA: unknown

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88

[github-actions]

Thank you for your contribution! Your PR has been merged.

We'd love to hear how your experience was: share feedback

[hivecommons-hive]

Read stable_promotion.go, stable_promotion_cache.go, channel_targeting.go and the saas_hives_api.go call site against v5. The refactor looks correct to me; one low-severity observation below, nothing blocking.

What I verified

• stablePromotionEligibleBuild keeps the old selection semantics: newest soaked verified build wins (sort.SliceStable by RunNumber desc, stable_promotion.go:217), else the soaking build with the earliest eligible that verifies (:218). The only behavioural addition is the stablePromotionMaxVerifiedRuns cap, which the body states.
• ttlFlight.get single-flight is sound: the in-flight call is published under c.mu before fetch() runs, waiters block on done, and the post-fetch re-init handles reset() racing a fetch (stable_promotion_cache.go:56–59). A failed fetch never overwrites a cached entry.
• stablePromotionFromTargets falls back to stablePromotionStatus when no stable row carries a status, so /api/saas/my-hives cannot regress to an empty payload (stable_promotion.go:303–310).
• The pkg/github/coverage_helpers_test.go addition is unrelated to the hub change; commit f5e9ecc says it exists to clear the 89% coverage floor, which matches the v2-ci per-package gate. Fine, just noting the scope for the maintainer.

Low: transient GHCR failures are cached as "not verified" for 5 min — stable_promotion_cache.go:126–135
stablePromotionVerifyBuild returns ok=true from the fetch closure in both branches, so a digest == "" or ghcrTagGeneration(...) == 0 caused by a GHCR timeout (fetchGHCRTagGeneration returns 0 on any HTTP error) is stored as a negative for channelDigestTTL (5 min, release_channels.go:144). By contrast cachedGHCRTagGeneration (:106–111) deliberately refuses to cache 0. Consequence: during a GHCR blip the card can skip the newest soaked build and advertise an older soaked build as the promotion candidate for up to 5 minutes. The code comment says negatives are cached on purpose (so a run whose image never landed doesn't re-hit the registry), which is reasonable — but a "tag missing" negative and a "lookup failed" negative are conflated here. If you want to keep the intent, caching the negative only when ghcrTagGeneration returned non-zero (i.e. the tag exists but carries a different generation) would separate the two. Advisory-only surface per the comment at channel_targeting.go:202–204, so I'd not hold the PR on it.

— hive: agent=reviewer backend=copilot model=claude-fable-5.1 copilot=1.0.88