[cboulay]

Stacked on #5 (base is fix/nonfinite-float-settings), so the diff here is just the two files below.

CI does not run on this PR: both workflows trigger only on pull requests targeting main or dev. Retarget this to dev once #5 merges and the checks will run. Everything was verified locally (see Verification below).

npm run build was broken on dev

src/components/topologyFlowData.tsx(526,45): error TS2345: Argument of type
'{ ownerId: string; ownerKind: ... | "scope_collection_stream" }' is not
assignable to parameter of type '{ ownerId: string; ownerKind: ... }'.

streamOwnerByAddress's value type and registerStreamOwner's parameter type were two hand-maintained copies of the same union, and only the parameter ever gained "scope_collection_stream". So both .set() calls in registerStreamOwner were type errors.

Only the type was wrong — the map has always held "scope_collection_stream" owners at runtime, and both consumers (ownerKind !== "orphan" at the orphan-node loop, and the explicit list in nodeIdForStream) already behave correctly for them. Declaring the union once as StreamOwnerKind / StreamOwner fixes the errors and removes the drift that caused them.

Why CI never caught it

Nothing in CI runs tsc. vitest strips types without checking them, and the e2e suite serves the app with vite dev (see playwright.config.ts webServer), which does the same. The production build is the only thing that typechecks, so this adds a npm run build step to the unit-tests job.

Verification

• npm run build: passes (tsc -b clean, vite emits 215 modules).
• npm test: 35 passed.
• npm run test:e2e: 24 passed, including the topology visual baselines — the rendering is unchanged, as expected for a type-only fix.

Also: catch stale packaged frontend assets (second commit)

The same blind spot in a different form. The server serves src/ezmsg/dashboard/_web, a committed copy of frontend/dist, and nothing verified the two agreed — they had drifted by months, so the packaged dashboard served a bundle far older than the source.

build_frontend --check already existed for exactly this; it now runs right after the build step above, with the fix spelled out in the failure message. It needs uv sync because importing the package pulls in FastAPI.

Verified both ways: the check passes on this branch, and mutating one byte of _web/index.html makes it exit 1.

No asset commit was needed here — this branch's change is type-only, so the emitted bundle is byte-identical to the one refreshed in #5.

🤖 Generated with Claude Code