fix(release): an expired fleet token must not take the whole fleet offline

[rubenvdlinde]

What broke

FLEET_DISPATCH_TOKEN (organisation secret, set 2026-08-21) expired thirty days later. Since 2026-09-20 every release run in the fleet has failed on Open the version-bump pull request:

HAVE_PAT: true
HTTP 401: Bad credentials (https://api.github.com/graphql)
##[warning]Could not enumerate open release pull requests to supersede.
HTTP 401: Bad credentials (https://api.github.com/graphql)
##[error]Process completed with exit code 1.

Confirmed on portaliq, dossiq, decidiq, openregister and thematiq. That step runs above packaging, tagging and the GitHub release, so nothing has shipped anywhere for two days. The job list read Open the version-bump pull request: failure and every step below it -.

Two defects

The fallback only covered an absent secret. secrets.FLEET_DISPATCH_TOKEN || github.token tests for the empty string. A secret that still exists and no longer authenticates passes that test, so GH_TOKEN carried a dead credential. The step now probes the token against the repository first and degrades to GITHUB_TOKEN on failure, the same way it already handled a missing secret. The follow-on warning says which of the two happened: "is not set here" would have sent a reader looking for a secret that was present and expired.

The step aborted the release, not the tidy-up. Its own comments claimed twice that it never fails the release because "the tag and the package are already published by the time this runs". That is not where this step sits, and believing it is why the failure was never handled. gh pr create now emits an error annotation and returns 0; the two comments now describe the real order.

Verification

The step was replayed with a stubbed gh:

case	before	after
PAT set, 401 on every call	exit 1	exit 0, error annotation, falls back to GITHUB_TOKEN
PAT set and valid (control)	keeps PAT	keeps PAT, no output
PAT absent (control)	original warning	original warning, unchanged

yaml.safe_load parses the file and bash -n accepts the step body with the GitHub expressions stubbed.

Still needs a human

This makes a dead token survivable, not correct. FLEET_DISPATCH_TOKEN still has to be rotated at the organisation level. Until it is, bump pull requests open with GITHUB_TOKEN and their checks do not run, which is the degraded path this workflow documents at length.

[rubenvdlinde]

Added the same probe to Sync the release branch back into development, which carries the identical secrets.X || github.token fallback and the identical blind spot. That step cannot fail the job, but with a dead PAT it opens no sync pull request at all, so development silently stops catching up with beta and the next promotion conflicts on the version file.