chore(ci): serialize e2e-api across runs to prevent docker collision

Now that the Molecule-AI org has two self-hosted Apple-silicon runners
(`hongming-m1-mini` + `hongming-m1-mini-2`) servicing the same label set,
two CI runs could execute the e2e-api job concurrently. Each run starts
fixed-name docker containers (`molecule-ci-postgres`, `molecule-ci-redis`)
bound to host ports 15432/16379 — a collision means the second run fails
with "container name already in use" or "port already in use".

Adds a workflow-level `concurrency: e2e-api` group to the job so GitHub
Actions serializes e2e-api executions globally regardless of which runner
picks them up. `cancel-in-progress: false` ensures later runs queue
rather than cancelling the in-flight one (we want every PR's e2e check
to actually execute, not get skipped by a newer push).

Tradeoff: e2e-api is now effectively single-threaded across the whole
org. Measured duration is ~1-2 min per run, so the added serialization
latency is small relative to total CI wall time. All other jobs still
parallelize across both runners.

.github/workflows/ci.yml

@@ -77,6 +77,14 @@ jobs:
     name: E2E API Smoke Test
     runs-on: [self-hosted, macos, arm64]
     timeout-minutes: 15
+    # Serialize across ALL CI runs globally. With multiple self-hosted
+    # runners, two e2e-api jobs could otherwise execute concurrently and
+    # collide on the fixed docker container names ($PG_CONTAINER /
+    # $REDIS_CONTAINER) and host ports 15432/16379. `cancel-in-progress:
+    # false` means later runs queue rather than cancel the current one.
+    concurrency:
+      group: e2e-api
+      cancel-in-progress: false
     # `services:` is Linux-only on self-hosted runners — we start postgres
     # and redis via `docker run` instead. Ports 15432/16379 avoid collision
     # with anything the host may already have on the standard ports.