Consider dynamic service startup in CI via workspace scripts

[jakebromberg]

Context

From PR #157 review by @AyBruno.

The CI integration test job currently hardcodes service startup:

node apps/auth/dist/app.js > /tmp/auth.log 2>&1 &
node apps/backend/dist/app.js > /tmp/backend.log 2>&1 &
timeout 30 bash -c 'until curl -sf http://localhost:8083/healthcheck ...'
timeout 30 bash -c 'until curl -sf http://localhost:8081/healthcheck ...'

The suggestion is to replace this with npm run start --workspace=apps/** so CI doesn't need updating when a new service is added.

Tradeoffs to consider

• Healthcheck URLs and ports are still hardcoded, so a new service requires CI changes regardless.
• Per-service log redirection (> /tmp/auth.log) enables the "Show service logs on failure" step. Running through npm merges output streams.
• Auth must be healthy before backend starts (JWKS dependency). A single workspace start command doesn't guarantee ordering.
• The start scripts would need timeout/healthcheck logic baked in, mixing CI concerns into app code.

When this becomes worth doing

If a third service is added under apps/, revisit this. A possible approach:

1. Add a ci:start script per workspace that wraps startup with healthcheck polling and log redirection.
2. Use npm run ci:start --workspace=apps/** with concurrency controls.
3. Or use a lightweight orchestrator script in scripts/ that reads workspace metadata.