ci: retry a hung visual shard on the label workflow

[mfal]

.github/actions/run-visual-shard has an attempts input for the flake it
documents, and defaults it to 1. Only one of its two callers passes it:

Workflow	attempts	Trigger
test-visual-scheduled.yml	"3"	cron
test-visual-label.yml	unset → 1	the run-visual-tests label — before now

So the path contributors are told to use was the one without the retry.
AGENTS.md says to add the run-visual-tests label proactively on any
styling/layout PR, which makes this the most-travelled visual path in the repo.

What it costs

Observed on #3076, a change that cannot move rendered output (an Option key
fix). run-visual-tests (2) went red with 85 failed tests across 22
scenarios, every one carrying the same message from testScreenshot
(packages/remote-react-components/src/tests/lib/environments.tsx:221):

Could not capture a stable screenshot within 5000ms.

Nothing was ever compared:

• 0 occurrences of pixels (ratio …) differ in the job log
• gh run download 33610043161 → "no valid artifacts found". The "Collect
  the visual diffs" step found no *-diff-*.png, because toMatchScreenshot
  never cleared its stability gate and so never wrote reference, actual or diff.
  The workflow's own summary already anticipates this shape: "a shard that
  failed before comparison … leaves none".

And it was the whole shard, not a subset: vitest list --project=visual --shard=2/6 returns 14 files, and all 14 failed — DonutChart, Kbd,
CodeEditor, TimeField and the rest. 63 of the 64 failure blocks were
firefox-linux. The five sibling shards passed, and the same commit was green
in test.yml's own visual shards.

A reviewer reaching that check sees a red gate with no diff images. The
cheapest-looking next move is the update-screenshots label — which runs
--update over the whole suite and git add -A, and is exactly how #2945
committed a tooltip-less frame as a baseline and kept the scheduled run red
(#2985).

Why the retry cannot hide a regression

The property that makes this safe, from run-visual-shard's loop:

• Each attempt runs the identical command, test:visual --shard=N/M, over the
  whole shard — not just the previous attempt's failures.
• test:visual is vitest run --project=visual --browser.headless. No
  --update. Only test:visual:update carries it, and the action never calls
  it. An attempt therefore cannot rewrite a baseline; it can only re-render and
  re-compare against the committed one.
• The loop exit 0s only when the entire shard passes; otherwise it falls
  through to exit 1.

A genuine diff is deterministic — same code, same baseline, same
browser/platform — so it reproduces on every attempt. The input's own
documentation states the invariant: "A real diff fails every attempt." What a
retry absorbs is only the non-deterministic case: a hung firefox process or a
runner too contended to produce two identical frames.

test.yml's visual job — checked, deliberately not included

It does not use the action. It calls vitest directly, --browser.name=webkit
only, with no retry of any kind. So it is not a second caller defaulting to 1;
it has no retry mechanism to switch on.

It is also materially less exposed rather than merely lucky: the documented flake
is a firefox hang, and that job never starts firefox — its own header says
"Using Webkit for now, because Firefox has issues with parallel visual tests."
The evidence matches, 63 firefox blocks to 1 webkit.

Not immune, though — that one webkit block was real. Left out of this PR anyway,
for two reasons: giving it a retry means either restructuring it onto the shard
action or duplicating a retry loop, and it is the visual job that the required
main check aggregates, so changing its failure semantics deserves its own
review rather than riding along in a one-line fix. Worth a follow-up.

Also

timeout-minutes 30 → 45, matching the scheduled workflow, so three attempts
fit inside the job. Otherwise a third attempt can be cut off and reported as a
cancellation instead of a clean retry. Passing shards on the observed run took
3m40s–4m46s, so the normal case is unaffected.

Not fixed here, noted for later: the 5000ms stability budget is vitest's default
and nothing in the repo raises it, while waitForPaintedContent right beside it
deliberately carries 20s with a comment that CI hardware is slower than the
machine its numbers came from. The same argument applies to the screenshot's
stability window.

Verification

prettier --check clean. Behaviour is CI-only, so it verifies by running: the
label path exercises this workflow on the next PR that uses it, and the
scheduled run has been on attempts: "3" all along.

🤖 Generated with Claude Code

[github-actions]

Coverage Report for ./packages/components/

Status	Category	Percentage	Covered / Total
🔵	Lines	78.69%	746 / 948
🔵	Statements	78.57%	763 / 971
🔵	Functions	80.09%	165 / 206
🔵	Branches	70.33%	377 / 536

File Coverage

No changed files found.

Generated in workflow #6545 for commit 52d393c by the Vitest Coverage Report Action

[github-actions]

🚀 Preview Deployment

Preview environments are ready:

Type	URL
docs	pr-3090.docs.review.flow-components.de
storybook	pr-3090.storybook.review.flow-components.de

Images:

• docs: ghcr.io/mittwald/flow/docs:pr-3090
• storybook: ghcr.io/mittwald/flow/storybook:pr-3090