ci: run independent steps in parallel

[dunglas]

GitHub Actions added native parallel steps: https://github.blog/changelog/2026-06-25-actions-steps-can-now-be-run-in-parallel/

Grouped independent steps that were previously run sequentially for no reason:

• tests.yaml (tests-linux): the four PHP-8.5-only lint/tidy checks (Go lint, Caddy module Go lint, go.mod tidy check, caddy/go.mod tidy check)
• windows.yaml (build): vcpkg install, Watcher download, PHP download — all independent and only consumed later by Prepare env
• docker.yaml (build): builder/runner metadata artifact uploads, which write to disjoint paths

Each group now takes as long as its slowest step instead of the sum of all of them.

Not touched:

• The -race test steps in tests.yaml, to avoid CPU contention on shared runners affecting the race detector
• The static.yaml manifest-push chains, since each side is itself a 2-step sequential chain rather than a single step

This is a brand-new (~6 weeks old) Actions feature not yet in the main workflow-syntax docs, so worth watching the first few CI runs closely — in particular whether lint.yaml's super-linter accepts the new parallel key.

[dunglas]

Measured actual before/after timing on real CI runs (main baseline vs this branch) before merging further:

tests.yaml (tests-linux, PHP 8.5 leg) — tidy checks only (lint steps stayed sequential, see below)

• Sequential (main): ~3s (1s + 2s)
• Parallel (this PR): ~1.6s
• Saved: ~1.4s — the job itself runs 4-9 minutes, so this is noise at job scale.

windows.yaml (build) — vcpkg install + Watcher download + PHP download

• Sequential (3 main runs): 50s, 44s, 60s (avg 51.3s)
• Parallel (2 runs on this branch): 47s, 49s (avg 48s)
• Saved: ~3-5s (~7%). vcpkg install alone takes 39-52s and dominates regardless of ordering — it's not blocked by the other two, so running them concurrently barely moves the needle.

docker.yaml (build) — builder/runner metadata upload

• Sequential (main): 2s (1s + 1s)
• Parallel: ~1s
• Saved: ~1s per matrix leg. Legs already run concurrently via strategy: matrix, so this doesn't touch overall workflow wall time — only trims ~1s off each leg's own job duration.

Total real gain across all three workflows: single-digit seconds. None of the candidates had steps long enough for max(steps) to meaningfully beat sum(steps).

Against that, the changes cost real coverage: VALIDATE_GITHUB_ACTIONS: false in lint.yaml disables actionlint repo-wide (not just for the new syntax), because actionlint 1.7.12 doesn't recognize the parallel step key yet (rhysd/actionlint#693). We'd be trading a real safety net across every workflow file for a few seconds.

Also worth noting: running golangci-lint concurrently for two different modules failed outright (Error: parallel golangci-lint is running) because it holds a machine-wide lock — that's why the lint steps aren't in the parallel group here.

Marking as draft. Not worth merging as-is; revisiting once actionlint supports the new syntax so we don't have to disable that check.