fix(compose): map the EVENT_LOOP_MONITOR_* knobs into the api service (#3236)

[bdunncompany]

Fixes #3236.

All three vars are documented as working knobs in apps/docs/src/content/docs/deploy/environment.mdx:207-209 and read at apps/api/src/services/eventLoopMonitor.ts (:71, :210, :497), but appeared in neither compose file's api environment: block. Compose only interpolates what is listed there, so setting them in .env was a silent no-op.

Mapped with the same ${VAR:-} shape as the DB_POOL_HEALTH_* block directly above them, in both docker-compose.yml and deploy/docker-compose.prod.yml.

Verified end-to-end, not just eyeballed

docker compose config against an .env that sets all three, rendering the api service:

	docker-compose.yml	deploy/docker-compose.prod.yml
before (a3dc568)	{}	{}
after	INTERVAL_MS=2000, STARVATION_WARN_MS=5000, DISABLED=1	same

vitest run src/config/ — 8 files, 303 tests, all passing (includes envComposeParity and composeBindMounts).

One correction to the issue

The issue says the vars are documented in ".env.example / deploy/.env.example". Only the root .env.example documents them (lines 452-454); deploy/.env.example has no EVENT_LOOP references at all. I did not add them there, because DB_POOL_HEALTH_* sets the precedent in the other direction — mapped in deploy/docker-compose.prod.yml, absent from deploy/.env.example. Happy to add a doc block to the droplet env example if you'd rather have parity there.

Why the parity guard didn't catch this

Worth flagging, because it is the actual root cause and it is not specific to these three vars.

apps/api/src/config/envComposeParity.test.ts builds its list of documented variables with:

const m = /^([A-Z][A-Z0-9_]*)=/.exec(line); // uncommented assignments only

The EVENT_LOOP vars are documented the way this repo documents optional knobs — commented out, showing the default:

# EVENT_LOOP_MONITOR_INTERVAL_MS=1000
# EVENT_LOOP_STARVATION_WARN_MS=1000
# EVENT_LOOP_MONITOR_DISABLED=

So the guard never considered them. That is a structural blind spot aimed squarely at the class of variable most likely to be forgotten: optional tuning knobs nobody sets on day one. DB_POOL_HEALTH_* is commented out too and only got wired because #3224 did it by hand.

Sweeping both pairs for commented-only vars that reach no container: 34 in the root pair, 5 in the droplet pair. Not all are bugs — several are legitimately host-level or web build-time — but each needs a map-or-allowlist decision, which is why I have not folded that into this PR. Filed as #3239 with the full list and the two policy questions it raises.

[bdunncompany]

The Trivy Filesystem Scan red here is not from this PR — its diff is two YAML files and touches no lockfile or manifest.

The blocking step reports 3 HIGH findings that arrived with a vulnerability-DB update: nanoid CVE-2026-67213 (fixable) and two image-size DoS advisories with no fixed version. It fails on every PR and will fail main's next security run.

Fixed in #3240, which I verified locally against the CI-pinned Trivy: control tree exits 1 with the same 3 findings, that branch exits 0. This PR should go green once #3240 lands and it is rebased.