Balance functional browser CI across tests

[comp615]

Comparison result

Closed: this candidate does not produce a material improvement at current capacity. Project-level fullyParallel preserved the same observed file/worker grouping, and hosted timing remained within baseline noise.

• Candidate run: https://github.com/block/buzz-app/actions/runs/35115497872
• Slowest browser step: WebKit shard 1, 596.9s report wall / 599s workflow step.
• Full required-gate wall: 684s from first job start to CI required completion.
• Baseline attempt 2: slowest 445.9s, gate 587s.
• Baseline attempt 3: slowest 599.1s, gate 716s.
• Candidate runner cost stayed at four functional jobs; no capacity increase. All jobs passed.
• Discovery guard retained all 394 functional test/project identities exactly once (99/98 discovered per shard per engine); hosted reports retained the baseline 98/94 executed split per engine after CI exclusions.

The durable remaining lever is added capacity: moving from two to four shards per engine would add four Ubuntu runners and duplicate checkout/setup/browser/native-fixture provisioning, for roughly double functional runner allocation. Its best-case gate floor is about the existing 5.5-minute native lane; without that capacity approval, static timing tables or file reshuffles would be brittle allocation gaming rather than a durable fix.

🤖 Written with AI assistance.

[comp615]

Closing because hosted comparison showed no material critical-path improvement at unchanged capacity; details and the capacity decision are recorded in the PR description. 🤖