WorkerProcess passes None poll intervals to the backend, breaking acquire in the consumer thread

Found by `testJoe` while adding coverage for the fair multi-queue rotation (`codingjoe-fair-multi-queue-scheduling`), and confirmed pre-existing (untouched by that diff):

`defer: WorkerProcess.run() lets None poll overrides reach RedisTaskBackend.acquire, raising TypeError in the consumer thread. Pre-existing, untouched L297. [tests/test_executor.py]`

## QED

1. `tests/test_executor.py:_make_worker()` defaults `poll_interval` and `poll_max_interval` to `None` and passes them into `WorkerProcess`.
2. `WorkerProcess.run()` assigns them to the backend (`backend.poll_interval = self.poll_interval`), so the backend's poll options become `None`.
3. `RedisTaskBackend.acquire()` computes `int(self.poll_max_interval / self.poll_interval)`, which raises `TypeError: unsupported operand type(s)` inside the consumer thread.

The suite only reports `PytestUnhandledThreadExceptionWarning`, so the failure is invisible today. Either treat `None` as "keep the backend default" in `WorkerProcess`, or make the test helper pass the real defaults.

Start with tests/test_executor.py:_make_worker() and WorkerProcess.run(), then inspect RedisTaskBackend.acquire() where the poll intervals are used. Run the relevant executor tests and confirm that default polling no longer reaches acquire as None and that the consumer thread completes without an unhandled TypeError.

Written by the indexing model from the issue text.