Rework the CI pipeline and run it locally with make ci

[kean]

The job matrix now lives in .scripts/ci.sh, and the workflow does nothing but hand it a group name, so make ci runs exactly what CI runs. This is what stops the drift that left .scripts/validate.sh unused for four years.

make ci                  # every job
make ci-list             # every job, group, and action
make ci-macos            # one GitHub job's worth
make ci-test-nuke-ios    # a single job
make test                # every test job, on every platform

A selector matches a job id, a group, or an action, so there is one way to run any slice of the matrix.

CI

• Rebalance the 5 macOS jobs (GitHub Free allows no more) instead of letting the iOS one dominate. Critical path goes from 16m24s to ~10m
• Run SwiftLint in CI for the first time — it had never been wired up. On a Linux runner, so it costs no macOS concurrency. Not --strict yet, since the existing warnings need clearing first
• Add compile-only coverage for visionOS, watchOS, and NukeVideo, none of which CI built at all
• Set permissions: contents: read; the token was write-all
• Resolve simulators at runtime instead of pinning OS=26.4.1, which forced a ci.yml change on every runner image update
• Upload xcresult bundles on failure, and report retried tests as flaky rather than letting -retry-tests-on-failure hide them
• Drop the stale validate.sh and install_swiftlint.sh (SwiftLint 0.47.1, pointing at a ./temp/ path that no longer exists), and test.sh
• Add dependabot for actions; move to checkout/upload-artifact v7

Bugs the missing coverage was hiding

• NukeVideo did not compile for watchOS, even though Package.swift declares .watchOS(.v8) and ships it as a product. VideoPlayerView.swift was missing the #if !os(watchOS) guard its two sibling files have
• The Xcode project could not build for visionOS at all — the project-level SUPPORTED_PLATFORMS omitted xros/xrsimulator

Flaky tests

Both registered an observer after the work it was supposed to observe had already started, so the notification could be missed.

• errorPropagatedToBothCoalescedSubscribers asserted coalescing without holding data loading until both tasks had registered, so the first could fail before the second subscribed and createdTaskCount came back as 2. It now uses the existing withSuspendedDataLoading helper
• cancellation created the Task before subscribing to MockDataLoader.DidStartTask, which loadData posts synchronously. Lose the race and nothing cancels the task, so it waited on a suspended queue until the suite's 5-minute .timeLimit killed it — a 300s hang, which is what the macOS job was failing on here

Reporting

Three cases where the old script would have reported green, or near enough to hide the problem:

• A test job that fails without any individual test failing (a hung test killed by its time limit, a crashed runner) no longer prints a clean 599 run · 599 ✓ tally next to a ❌
• The test count is taken from the first run rather than the last, since -retry-tests-on-failure re-runs only the failures and the last tally counts a subset
• A local run without SwiftLint installed reports the job as skipped rather than passed