Add a configurable cap on concurrently running jobs

POST /jobs unconditionally spawns a worker task for every request, regardless of how many jobs are already running. In this simulated service that just means more concurrent asyncio.sleep() calls, but this project's own README frames the simulated "transcode" as a stand-in for a real, resource-hungry job (a real transcoder's CPU/GPU budget). A real backing implementation would have a hard concurrency ceiling somewhere -- worker processes, GPU slots, external API rate limits -- and nothing in this service protects it. A traffic spike, a buggy client retry loop, or just organic growth in usage would all hit that ceiling by simply overwhelming it, with this service doing nothing to prevent, queue, or even report on it happening.

Settings.max_concurrent_jobs already exists as a config knob for exactly this, but nothing reads it.

1. pytest practice_tickets/tests/test_ticket_15_no_concurrency_cap.py -v
2. Observe: with max_concurrent_jobs=1, two jobs submitted back to back both start immediately -- jobs_in_progress rises by 2.0 instead of the expected +1.

This is a genuine concurrency-control problem, not just "add a condition before spawning the task" -- the desired behavior is closer to a bounded work queue: accept the job immediately (the caller gets a real job_id back right away and can start polling it), but don't let its actual work begin until capacity exists. Whatever gates this has to be shared across every job's worker, held for the job's entire active lifetime, and released reliably even when a job fails or is cancelled midway through -- get that release wrong and every job after the first max_concurrent_jobs failures/cancellations queues forever with no possible way to make progress.

app/main.py's /lifespan is the natural place to own a single shared across every job (mirroring how it already owns ) -- needs a decision here too, since a semaphore can't take an unlimited value. 's is where a slot would need to be acquired before the job's real work begins and released once it ends, no matter which of the three ways it ends -- the block already established for / is the right place to think about "always runs, no matter how the job ends."