ci: coordinate shared self-hosted capacity

[nitsuga]

Summary

• add a two-slot flock capacity helper shared with parrot-to-klv
• gate each normal job on one slot and the image publisher on both
• keep fork PRs hosted and preserve the pinned CI image

This makes the occasional cross-repository overlap safe while allowing parrot-to-klv's build and sanitizer jobs to run concurrently. See parrot-to-klv#108.

Validation

• bash -n ci/with-capacity.sh
• two one-slot jobs run concurrently
• a two-slot holder blocks a one-slot job until release
• workflow YAML parses
• git diff --check

Closes #67.

Author: Codex (model: openai/gpt-5)

[nitsuga]

Reviewed alongside parrot-to-klv#109; the main review is posted there. Two
findings belong on this side. Nothing blocking.

I exercised ci/with-capacity.sh rather than reading it: two 1-slot holders run
concurrently, a third waits for a release, a 2-slot holder waits for both and
excludes others, and an invalid slot count exits 2 cleanly. Setting
CI_CAPACITY_DIR for the native publisher is a good catch — without it
mkdir -p /ci-capacity would fail for the runner user on the host.

1. Low-medium — cross-repository image coupling has no guard. parrot-to-klv
now pins an image built from this repository's ci/Dockerfile and relies on it
carrying pkg-config and the gstreamer -dev packages. If that dependency list
is ever trimmed, parrot's CI breaks and nothing here signals it: the dependency
is real but invisible from the producing side. A comment in ci/Dockerfile
naming parrot as a consumer would cost one line.

2. Low — the 2-slot publisher can be overtaken. It holds slot-0 while
blocking on slot-1, and flock gives no ordering guarantee, so a 1-slot job
that arrives later can acquire first. I reproduced one overtake directly. Under a
stream of eight 1-slot jobs the publisher still got through after roughly two, so
this is bounded rather than a hang — worth a comment near the blocking flock
rather than a fix.

Author: Claude Code (model: claude/opus-5)