Drop bail from integration-test jest config

[jakebromberg]

Summary

• Remove \"bail\": 1 from jest.config.json (integration suite).
• Update CLAUDE.md doc line that referenced the bail behavior.

Why

bail: 1 masked the BS#955 cascade pattern. When G4's process-wide TokenBucket(50/min) drained, the suite reported only the first failing spec (metadata-lml.spec.js) and exited, hiding that subsequent integration specs were also queueing on the same exhausted bucket. The post-incident analysis showed several specs that would have failed visibly under a non-bailing run, which would have pointed at the rate limiter as the root cause hours earlier instead of letting it look like a metadata-lml-specific bug.

With the limiter env vars now correct in both CI surfaces (BS#957 — workflow Start services env block + dev_env/docker-compose.yml), the integration suite is stable enough that the diagnostic value of full failure visibility outweighs the CI-minute savings from short-circuiting on first failure. The suite runs --runInBand with a 30s per-test timeout — even a worst-case 6-failure run adds only ~3 minutes of CI time.

Test plan

• CI Integration-Tests job runs to completion (it should pass on green; this PR only affects what happens when a failing test exists).
• No other consumers of the bail config — confirmed via grep -rn 'bail' --include='*.md' --include='*.json' --include='*.ts' --include='*.js'; only jest.config.json and CLAUDE.md mention it.

Related

• BS#957 — the limiter env-var fix this builds on.
• BS#955 — the incident that exposed bail's diagnostic cost.