feat(producer): add request-level render concurrency semaphore

[jrusso1020]

What

Add a request-level FIFO semaphore to the producer server that limits how many renders execute simultaneously.

Why

Parallel renders cause Chrome CPU contention — when multiple Chrome instances compete for CPU, beginFrame calls fail because the compositor can't
produce frames within the deadline. This semaphore ensures renders are queued FIFO so only N renders run at once (default 2), preventing the contention
that triggers beginFrame timeouts even with the retry logic from #230.

How

• Semaphore utility (packages/producer/src/utils/semaphore.ts): Simple async counting semaphore with FIFO queue. acquire() returns a release function; callers hold the slot until they call release().
• Blocking render handler (POST /render): Acquires the semaphore after input validation but before starting the render. Releases in finally so the slot is freed even on errors.
• SSE render handler (POST /render/stream): Same acquire/release pattern. Additionally sends a "queued" SSE event if the request must wait, so clients know their position.
• Queue status endpoint (GET /render/queue): Returns { maxConcurrentRenders, activeRenders, queuedRenders } for observability.
• Configuration: HandlerOptions.maxConcurrentRenders option, PRODUCER_MAX_CONCURRENT_RENDERS env var (default: 2), and --max-concurrent-renders CLI flag (1-10).

Test plan

• Unit tests for Semaphore class (acquire/release, FIFO ordering, concurrent limit)
• Manual testing: send 4 concurrent render requests with maxConcurrentRenders=2, verify only 2 execute at a time
• Verify GET /render/queue returns correct counts during concurrent renders
• Verify SSE stream receives "queued" event when semaphore is full
• Verify release() fires in finally even when render errors — no semaphore leak
• Verify --max-concurrent-renders CLI flag validates range 1-10