refactor(ci): standardize workflows and add retry mechanisms and centralized config

[teodorciuraru]

Summary

Refactored all 11 BrowserStack CI workflows to handle BROWSERSTACK_ALL_PARALLELS_IN_USE capacity errors through comprehensive retry mechanisms and centralized configuration.

What Changed

Retry Mechanism

Added 5-attempt retry with 15-minute waits to all BrowserStack workflows. Each retry performs the complete test lifecycle (seed → build → upload → execute → wait) to ensure test documents exist in Ditto Cloud.

Extended Timeouts

Increased job timeouts to 150 minutes to support full retry cycles without premature cancellation.

Centralized Device Configuration

Created .github/browserstack-devices.yml with comprehensive inline comments explaining device selection criteria, OS coverage, and links to BrowserStack documentation. All 11 workflows use yq for config parsing.

Test Reliability Improvements

• Device-level status checking (not just build-level)
• Auto-grant permissions to prevent potential issues
• Standardized timeout polling patterns using MAX_WAIT_TIME (18 min) instead of iteration loops

Standardization

• Consistent timeout values (150 min) across all BrowserStack jobs
• Consistent wait times (18 min) for polling using MAX_WAIT_TIME pattern
• Consistent workflow naming ("{Platform} CI")

CI Triggers

All workflows use pull_request and workflow_dispatch triggers only. They run on PR updates but NOT on merge to main to save BS capacity.

BrowserStack Dashboard Integration

Created reusable composite action .github/actions/generate-browserstack-names that auto-derives BrowserStack project names from workflow context. All 11 workflows now use this centralized action.

Project Name Auto-Derivation

• Pattern: Workflow name → quickstart - {Platform}
• Example: "JavaScript Web CI" → quickstart - JavaScript Web
• Zero config: No hardcoded project names needed
• Eliminated: 11+ hardcoded project-name inputs across workflows

Build Name Status

• Status: Currently returns empty string (documented with FIXME)
• Issue: Build name generation using GitHub CLI/event context is unreliable; we couldn't get it to work in time.
• TODO: Needs proper implementation in future PR

Benefits

• Single source of truth for project naming
• Automatic consistency across all workflows
• Less maintenance (action renamed from get-browserstack-build-info)
• Clear documentation of what works vs. what needs fixing

Shortcomings (WIP)

• We still want the Build Names on BrowserStack to reflect the PR title and commit message for easier identification.
• We still want all BS workflows to have a link to the exact BS build.

[teodorciuraru]

Resuming

Clicking the "view test results" link here doesn't take me to the JavaScript Web results page. Is it the same for you @teodorciuraru ?

Yes. We'll move making links work in summaries to a follow-up ticket.

[teodorciuraru]

Taking this PR to In Review. It has both WIP but also refactorings that will help on main. We'll tackle the WIP via follow-up tickets, while pointing out the shortcomings in the PR description.

[Copilot]

Pull Request Overview

Copilot reviewed 48 out of 49 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

.github/actions/generate-browserstack-names/action.yml:1

• The build name functionality is intentionally disabled with a FIXME comment. This incomplete implementation should be tracked and completed, as build names are important for identifying test runs in BrowserStack.

name: 'Generate BrowserStack Names'

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[pvditto]

LGTM

[teodorciuraru]

• Waiting on code owner review from busec0, konstantinbe, kristopherjohnson, and/or phatblat.

Yep, we're missing several of these. We'll follow-up with fixes later.