fix(live): epoch heartbeat, checked mode declarations, dated areas with a weekly refresh

[NateIsern]

This PR handles the follow-ups from the final review of #168. Each fix has a test, and I checked that the test fails without the fix.

1. Lower-epoch window lapsing between slow polls (hub.ts, cluster.ts)

• Every coordination round (2 s), a leader now publishes a small epochs message with the epoch of each source it holds.
• A follower counts that heartbeat as "heard", so its mark stays fresh even for a source polled every 60 s.
• The window that accepts a lower epoch (meant for a counter lost in a failover) therefore stays closed while the leader is alive. A late publish from an older holder is dropped. After the leader has been gone for a whole lease, a lower epoch is still accepted, as before.
• Test: cluster.test.ts → "a live leader heartbeats its epoch…". It runs 40 s with no poll answered, then delivers a stale publish. The test fails with the heartbeat disabled.

2. Declared transit modes match what a source emits (modes.test.ts)

Every source's transitModes must include:

• every mode its adapter emits (checked by polling each transit adapter with a synthetic VehiclePositions feed);
• every mode its operator's routes.txt names. The hub gives each vehicle its route's mode, and live:areas records those modes.

A source neither check can reach fails the test. The test showed three catalogue declarations were too narrow, now corrected:

• Renfe: add bus (replacement buses).
• FGC: add subway, cable and bus (Vallès metro lines, rack railways and funiculars, connecting buses).
• Subway feed: add rail (the Staten Island Railway).

Providers no longer declare their modes by hand. Their transitModes are their default mode plus every mode their routes name, so mixed feeds like Calgary's and Vancouver's can't be mis-declared.

Verified failing: a deliberately wrong declaration fails both checks.

3. areas.generated.ts is dated, fingerprinted and refreshed

• The file now opens with a header listing each feed, the date its inputs last changed, and a SHA-256 of the stops' positions and route types. Re-running over unchanged data rewrites nothing, and a source whose server is down keeps its previous entry and date. areas.test.ts checks every entry has a date and a fingerprint.

• New workflow: .github/workflows/live-areas.yml runs weekly and can be started by hand. It:

  1. regenerates the file;
  2. runs the area and mode tests on the new data;
  3. when anything changed, opens a pull request whose body says whether those tests passed.

  The tests run inside the workflow because a pull request opened with the workflow's own token doesn't start CI.

  Owner action: opening that pull request needs the repository setting "Allow GitHub Actions to create and approve pull requests". Without it the run fails visibly rather than silently.

4. CI builds packages/contracts before the backend tests: checked, no change needed

• The Backend tests job runs bun install --frozen-lockfile --ignore-scripts, then Build the contracts, then migrations and tests. The backend resolves @goway/contracts through its main (dist/index.js), so the tests always run against freshly built contracts.
• Build, typecheck and lint builds the contracts and the SDK before typecheck and before the frontend and SDK tests.
• Repository gates reads contracts from source (OpenAPI and JSON Schema checks).

Checks run locally

• Backend: 1,209 tests against a real Valkey.
• SDK: 208 tests. Frontend: 1,640 tests.
• bun run lint, bun run typecheck and check:openapi are clean.
• The live suite was re-run after rebasing onto main (210 tests).

🤖 Generated with Claude Code