Console build never emits maplibre's sibling worker — /_console/assets/maplibre-gl-worker.mjs 404s on every map page #3297

What happens

Every visit to a page carrying an ObjectMap widget fires a 404 for a local
console asset:

404 /_console/assets/maplibre-gl-worker.mjs

Reproduced on showcase_task_map
(/_console/apps/com.example.showcase/page/showcase_task_map) against a
vendored console built from f5bc4c78be76.

Why

maplibre-gl's ESM distribution resolves its worker as a sibling of its own
script URL rather than importing it, so the bundler never sees an edge to
follow. From the built chunk assets/maplibre-gl-DXuUDjK2.js:

let t = e.endsWith(`-dev.mjs`) ? `maplibre-gl-worker-dev.mjs` : `maplibre-gl-worker.mjs`;
return new URL(`./${t}`, e).href

Vite bundles maplibre-gl into a hashed chunk under assets/ and emits nothing
beside it, so that computed URL resolves to /_console/assets/maplibre-gl-worker.mjs
— which does not exist:

$ ls packages/console/dist/assets | grep -i maplibre
maplibre-gl-DXuUDjK2.js
maplibre-gl-DXuUDjK2.js.br
maplibre-gl-DXuUDjK2.js.gz

$ curl -o /dev/null -w '%{http_code}' http://localhost:3000/_console/assets/maplibre-gl-worker.mjs
404

apps/console/vite.config.ts lists maplibre-gl in optimizeDeps.include
(~L219) but nothing arranges for the worker file to ship.

Scope / severity

This is not the same thing as the external-tiles failure. On the same page
the demo style is also unreachable here:

Map failed to load (AJAXError: Failed to fetch (0): https://demotiles.maplibre.org/style.json).
Markers below are still listed in the search box; configure a custom map style for production use.

That one is this sandbox's egress policy, and the widget degrades gracefully
with a clear message and a listed-markers fallback — working as designed.

The worker 404 is different: it is a first-party asset missing from our own
build, so it 404s in every deployment, air-gapped or not.

What I could not determine here: whether the missing worker alone breaks
tile rendering, because external tiles are blocked in this environment, so I
could never get a map to paint. It should be confirmed against a reachable
style URL (or a self-hosted one) before deciding how urgent this is — maplibre
may fall back to main-thread parsing, in which case the user-visible cost is a
404 plus a slower map rather than a blank one.

That same limitation is why I am filing this rather than fixing it: I cannot
verify a fix end-to-end from here.

Suggested direction

Emit the worker next to its chunk, e.g. a small vite-plugin / generateBundle
hook (or viteStaticCopy) that copies maplibre-gl/dist/maplibre-gl-worker.mjs
into assets/, and a build assertion so a future maplibre bump that renames it
fails loudly instead of 404ing at runtime — the same "no silent drift" posture
scripts/build-console.sh already takes with its CONSOLE_BUNDLE_CANARY.

Repro

1. os dev --ui --seed-admin in examples/app-showcase
2. Sign in, open /_console/apps/com.example.showcase/page/showcase_task_map
3. Network panel → maplibre-gl-worker.mjs 404

Found while browser-sweeping showcase + Studio for objectstack#4879.