Future: reconsider worker/queue service split if scaling changes

[koolamusic]

Parked from deployment planning session.

Current

All four BullMQ workers (extraction, link, regen, provision) run inline in the core Node process via `startWorkers()` at `core/src/index.ts:153`. Single container, single event loop.

When to revisit

• Multi-tenant migration (workers would need fair scheduling across tenants).
• Ingest volume large enough that worker CPU contends with HTTP serving.
• Need to restart web without interrupting in-flight regen jobs.

If split

Separate Railway service running a thin `worker-index.ts` entry that only calls `startWorkers()` without starting the Hono HTTP server. Same Redis, same DB, no HTTP ingress.