feat(ci): gate the shape ADR-0022 exists for

[ttncode]

What this changes

scripts/deploy-check.sh takes a list of adapters instead of one. It builds every target the project publishes, tags each separately, waits for each container, and curls each application on its own port. .github/workflows/adapters.yml gains deploy-multi-app, running nextjs nestjs --db postgres weekly.

Why

The gate asserted expected exactly one build target, and every deploy job in adapters.yml runs one adapter at a time. So the multi-application shape — the thing ADR-0022 changed the whole image and compose layout to make possible — was covered by no gate at all.

I verified it once by hand earlier in this session, on a repository I then deleted. That is not a gate; it is a memory of a gate.

deploy-multi-app is weekly rather than per pull request, like compose beside it: two generations plus two image builds. The schedule notifier lists it, because a weekly lane nobody watches is theatre — that is the notifier's own comment, and it was already true of the jobs it did list.

Two ADRs asserted the old limit and now say otherwise: ADR-0021's "gate 2 covers one image, not a project" bullet is retired, and ADR-0022 records what the gate covers now.

How it was verified

Run locally against a real two-application stack:

waiting for the web container to become healthy (up to 120s)...
waiting for the api container to become healthy (up to 120s)...
web liveness (http://localhost:8080/api/health/live): 200
web: nextjs declares no readiness path — skipping readiness check
api liveness (http://localhost:8081/health/live): 200
api readiness (http://localhost:8081/health/ready): 200
nextjs nestjs stack serves HTTP and reaches its database

Two images built, two containers healthy, each application answering on the port add_app_service allocated it, and the api's readiness reaching the database.

The single-adapter path was run before and after the change and is unchanged (nestjs --db postgres, liveness and readiness both 200). The per-adapter deploy jobs here exercise it again on every run.

One bug the real run caught: COMPOSE_PROJECT_NAME was built with ${APPS[*]// /-}, which substitutes inside each element rather than on the joined string, so the join space survived and compose rejected deploy-check-web api. Both images had already built at that point — the failure was purely the name.

Not exercised: the new count assertion (expected N build target(s)). Its negative path is a comparison of two integers, and the failure paths around it — unhealthy container, non-200 curl — are the same die calls the single-adapter run has always had.

Checklist

• mise run lint passes
• mise run test-runner passes
• New behaviour has a test that fails without the change
• Docs that describe changed behaviour were updated in the same commit
• No unrelated changes