revert: retry a hung visual shard on the label and scheduled visual runs

[mfal]

Reverts #3090, and removes the same retry from the scheduled run.

The premise did not hold. #3090 read the whole-shard failure — every test in one shard reporting Could not capture a stable screenshot within 5000ms, 63 of 64 blocks on firefox-linux — as a hung browser process, and gave the label path three attempts against it.

The first real exercise of that retry was run 33633352648 on #3104. It ran all three attempts: 118 of 120 tests failed each time, in both browsers, 1110s in total. Shard 1 of the same PR's test.yml run did the same — 85 of 86 tests, at 474s, 472s and 472s. The attempts share the runner, so a machine that produces this failure produces it three times.

So the retry buys nothing on the observed evidence, and it costs the label path 15 minutes of timeout-minutes plus up to 3× the runner time whenever a diff is genuine — the case where a reviewer wants the diff artifacts quickly.

Two commits, because only one of them is a revert

Revert #3090 — attempts: "3" and timeout-minutes: 45 off the label path, back to 30. A plain git revert, one file.

The scheduled run is not #3090's doing, so removing its retry is a change rather than a revert. It is where the retry started: three attempts as a step-level loop over the whole unsharded suite, from before #3006 sharded it, on the same firefox-hang reasoning. Same evidence applies, so it goes too. Nightly runner time is cheaper than a PR's, but three identical failures buy nothing at any price, and the red they report is unchanged.

Its timeout goes 45 → 30 as well, the label path's number for this same shape at one attempt. 45 was sized for the unsharded job, where a single attempt took 24-34 minutes.

What stays

attempts stays on .github/actions/run-visual-shard, now with no caller. It documents a real mechanism for a hang that shows up on its own, and deleting the loop would reach past this revert into #3006. Its description now names the failure it does not cover and points at #3106. Say the word and I strip it.

What remains open

The failure itself is #3106, with the five main runs it hit and the lead #3090 already noted: toMatchScreenshot runs on vitest's default 5000ms stability budget, while waitForPaintedContent right beside it deliberately carries 20s for slower CI hardware.

After this, nothing retries a visual shard anywhere, so #3106 reports as a plain red shard with no diff artifacts until it is fixed. #3104, which wired the same retry into test.yml, is closed for the same reason.

related #3090, #3106

🤖 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 #6596 for commit 2a0b656 by the Vitest Coverage Report Action

[github-actions]

🚀 Preview Deployment

Preview environments are ready:

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

Images:

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