ci: repair the project-reference wiring and add a CI workflow

[stormer78]

Follow-up to #94/#95, closing the stale-dist trap. Investigating it turned up two problems larger than the one I set out to fix.

1. npm run lint was broken in every workspace that references another

tsc -b --noEmit is invalid when a referenced composite project must emit — TS6310. So:

workspace	npm run lint before
core	pass (no references at the time)
tsp-js	pass (no references)
extension	fail — TS6310
pwa	fail — TS6310

The two packages that actually consume core failed the instant the command ran. Only build was ever typechecking anything. Lint is now plain tsc -b in all four; the leaf tsconfigs already set noEmit, so they still emit nothing but .tsbuildinfo while their references build properly.

I should flag that I reported "lint clean" on #95 — that was wrong. I misread a $pipestatus index and read a failing command as passing. The lint failure predates #95, but I stated it was green without it being green.

2. core had no project reference to tsp-js

core imports @openvtc/vti-tsp-js and typechecks against its emitted dist, but declared no reference. tsc -b had no idea it must build tsp-js first, so a missing dist surfaced as Cannot find module '@openvtc/vti-tsp-js' inside core's own, entirely correct, source.

This is the same failure that cost time on #94, one level further down — and unlike that one it could not self-heal, because no reference existed for tsc -b to follow. Added it, plus the missing tsp-js entry in the root solution tsconfig.

3. There was no CI at all

No .github/workflows. Neither build, lint, nor tests ran on a PR — DCO was the only check, which is why both problems above could sit there. Added a workflow running lint → build → test on Node 20 (the engines floor) and 22, from a cold checkout so the reference wiring stays honest: if it regresses, CI fails instead of the next person's clone.

It also asserts the MV3 invariant from #95 — dist/background.js must be a single bundle with no dynamic import(). A service worker cannot load one (w3c/ServiceWorker#1356), so losing Rollup's codeSplitting: false in a future upgrade would break the worker in users' browsers behind a green build.

Verification

• Each workspace lints from a cold tree individually (all build state wiped before each) — 4/4 pass
• All workspaces lint together from cold — 4/4 pass
• Clean npm run build — pass
• npm test — 171/171 (42 tsp-js + 129 core)
• Full CI sequence re-run against a fresh npm ci — pass
• Bundle guard checked against a planted import() to confirm it catches one rather than being a vacuous grep

Not verified: the workflow has never executed on GitHub Actions — this PR is its first run, so watch the checks here. npm ci emits allow-scripts warnings (esbuild, @swc/core, cbor-extract) under npm 11; the full sequence passes with those scripts unrun, but if a runner behaves differently that's the likely spot.

Pre-merge checklist

• No new reqwest::Client::new() / bare fetch(); timeouts (R1.2) — no network code
• No lock held across a network await (R1.3) — n/a
• No local state committed before its remote effect (R2.1) — n/a
• Every retry bounded + backed off (R1.4) — n/a
• Accept/poll/listen loops survive transient errors (R1.5) — n/a
• Acks/deletes only after durable handoff (R1.6) — n/a
• New/changed wire types (R3.*) — none
• Config absence = most restrictive; fail-closed (R5.*) — the bundle guard fails the build when the asserted file is absent rather than skipping
• Logs/status claim only what was verified (R6.*) — CI asserts the MV3 invariant instead of assuming it
• "Process dies on the next line" answered for every mutation touched (R2.1) — no runtime code changed
• Deviations flagged with rule numbers — none