Batch acquire: take up to N tasks per call across non-empty queues

Split out of #48 during the fair multi-queue scheduling change (`codingjoe-fair-multi-queue-scheduling`).

`defer: Batch acquire (fetch up to N tasks per call across non-empty queues). Needs executor fetch-and-dispatch; the lease would tick while tasks wait in-process. [threadmill/backends/redis.py]`

## Why

`acquire()` pops a single task per script call, so a process with `--threads 4` performs four Redis round trips to fill its threads. A batch acquire that spreads up to N tasks across the non-empty queues would cut round trips and drain several queues in parallel.

## What makes it non-trivial

- `WorkerProcess` runs one `WorkerThread` per thread, each calling `acquire()` itself. A batch would need a fetch-and-dispatch step, since a single thread cannot execute N tasks at once.
- `acquire.lua` moves the task into the running set with `deadline = now + lease_ttl`. Tasks prefetched into an in-process queue would burn lease budget while waiting, so the reaper could fail them, or the lease clock has to start at execution instead.
- Graceful shutdown must return prefetched, unstarted tasks to the ready set instead of leaving them to be reaped as FAILED.

Pop and move must stay inside one script call.

Read threadmill/backends/redis.py and acquire.lua first, then trace WorkerProcess and WorkerThread to understand the current per-thread acquire flow. Define how fetch-and-dispatch handles lease timing, graceful shutdown, and prefetched tasks, while keeping pop and move in one script call. Done means up to N tasks can be acquired across non-empty queues without stranded or prematurely failed work.

Written by the indexing model from the issue text.