ci(java): split java lane into fast/slow + shared PG sidecar (~3× faster, crash-resistant)

[dmealing]

Problem

The Java local-ci job took ~10m and intermittently died to runner shutdown/cancel ("received a shutdown signal / operation was canceled"). Two root causes: (1) it ran the full 14-module reactor + double-conformance + JaCoCo single-threaded, and (2) local-ci.yml never wired the shared Postgres sidecar, so java+kotlin integration booted ~30-40 serial Testcontainers Postgres — the main wall-clock sink and, contending on one Docker daemon with the other 3 ports, the crash vector.

Changes

• Split java into two parallel jobs. java-fast (java+kotlin conformance — the correctness signal) and java-slow (full reactor + docker integration). A cancel/OOM mid-integration no longer kills the fast verdict. ci-local.sh grows --only java-fast|java-slow; --only java (and a plain local run) still runs both lanes in order, byte-equivalent to before.
• Shared Postgres sidecar for every integration-running job (ts/python/csharp/java-slow). Each port already honors METAOBJECTS_TEST_PG_URL and CREATEs a per-scenario database. The sidecar publishes 5432 to a dynamic host port so concurrent jobs on the shared self-hosted host never collide on a fixed port.
• Skip JaCoCo in the reactor (-Djacoco.skip=true) — its coverage gate is haltOnFailure=false, so it's pure instrumentation overhead for a pass/fail signal.
• Deliberately not adding -T 1C: this reactor has a documented shared-render-jar race under parallel module builds (integration-test.sh).

Verified

Full workflow_dispatch run on this branch — all jobs green:

Job	Before	After
java (combined)	~9.8m	java-fast 0m46s · java-slow 3m00s (parallel)
ts	5.3m	2m17s
python	2.6m	0m34s
csharp	2.0m	0m56s

Java correctness signal: 10m → <1m. Full Java lane: ~3× faster. Every port benefits from removing the shared-daemon container contention.

🤖 Generated with Claude Code