## Why
The PR drain became a CI-wait treadmill. A 4-lens council (2026-06-06)
found three non-quorum-sensitive, mutually-reinforcing fixes. (Merge
queue — the obvious answer — is **impossible**: it's org-only and this
is a user-owned repo; strict-up-to-date was relaxed permanently
instead.)
## What
1. **`concurrency` cancel-in-progress (PRs only).** validate.yml had no
concurrency group, so every update-branch/force-push left stale runs
consuming the 20-slot free pool — a self-DoS that produced a 19-deep
queue. Now superseded PR runs cancel; **main/tag pushes never cancel**
(`cancel-in-progress` is false unless pull_request).
2. **4-way parallel bats.** Serial `bats tests/scripts/*.bats` was ~237s
= **55% of the `correctness` critical path**. `--jobs 4
--no-parallelize-within-files` targets ~150s off every run (within-file
order preserved; only independent files run concurrently). Installs GNU
`parallel`.
3. **`.gitattributes merge=union`** on `registry.json`,
`*.agentops-generated.json`, `context-map.md`, `COMMANDS.md` — kills the
O(n²) textual re-conflicts these generated files cause during multi-PR
drains (regen-all restores canonical bytes). `cli/embedded/**` +
`skills-codex/**` stay committed (go:embed / tarball-shipped).
## Risk / trial
Only #2 carries risk (parallel test collisions) — **this PR's own
`correctness` run is the live trial**: if a bats suite collides under
`--jobs 4`, correctness fails here and I drop it. The required-check SET
(`summary`) and its semantics are unchanged, so this is not
quorum-sensitive.
Closes-scenario: ag-bdg1#ci-throughput
Bounded-context: BC5-Runtime
Evidence: .github/workflows/validate.yml
Bo