[T-069] The service has no request queue — it rejects the moment all worker slots are busy, instead of queueing with bounded backpressure

[Ztein]

Canonical ticket: docs/tickets/T-069-request-queue-bounded-concurrency-backpressure.md

Concurrency control on the HTTP surface is a bare semaphore with a reject-if-busy pre-check (api.py, shared run_conversion): if no permits are left the request is 429'd immediately. Single-tenant deployments cope via client-side retry, but any bursty consumer (a RAG pipeline ingesting a batch) hits a wall of immediate rejections with no way to hand figmark a short queue of work.