Answer an unknown compiler with 404 instead of queueing it

[partouf]

Fixes #12.

A compiler id missing from the routing table, such as a stale bookmark or a renamed compiler, used to fall through to the default queue. A worker then failed with Compiler with ID … not found, and the caller got a 200 with code: -1. Now the router answers it with a 404 before subscribing to results or queueing anything. The compilation endpoint does the same when it is served directly.

• lookupCompilerRouting returns null when neither the composite key nor the legacy key has a row.
• That miss is cached for 60 seconds, not indefinitely, and /admin/clear-cache drops it.
• A DynamoDB error is not treated as a miss. It still falls back to the coloured queue, so a table outage doesn't turn every compile into a 404.
• The routing lookup now happens before the WebSocket subscribe, so an unknown compiler never subscribes and never waits on the events socket.

On the fail-closed concern in the issue: the deploy writes the routing table in Step 6, while the ~20-second colour switch is still propagating, and Step 6.5 clears the router caches. So a compiler added in a deploy has its row before users can reliably reach it.

On language undefined: the router already passes lang through when the client sends it, in the body or as a query parameter. The worker searches every language when lang is missing, so only the wording of that error message is misleading.

Tests

• Unit tests: a missing row gives null, a DynamoDB error still queues, a cached miss expires after its TTL, and a cache clear forgets it.
• Integration tests: compile, cmake and prefixed build/:buildSystem routes each return 404 without queueing, even when subscribing would have failed.

🤖 Generated with Claude Code