Toy System: An In-Process Job Runner

This first toy system begins from requirements rather than an existing API. We need one in-process runner for async I/O jobs with:

• one FIFO queue holding at most queue_capacity waiting jobs;
• at most concurrency_limit running jobs;
• async backpressure when the queue is full;
• a typed result handle for every submission;
• no cancellation when that handle is dropped; and
• shutdown that rejects new jobs, drains accepted jobs, then returns.

Persistence, retries, priorities, distributed workers, CPU scheduling, and exact byte-based memory limits are deliberately absent.

Design thesis

Use one bounded channel to route heterogeneous work into the runner, and one private typed oneshot channel per submission to route its result back.

That decomposition gives each mechanism one job:

many submitters → bounded MPSC<ErasedJob> → dispatcher → running futures
       caller ← oneshot<Result<T, E>> ←──── wrapper around its one future

The complete runnable crate lives at examples/toy-job-runner.