Workers poll at ~1s max regardless of `poll_interval` setting

# Overview

We wanted to slow down the poll interval for our workers to something like 5s to reduce the load on the servers, but noticed that they continued to poll at around a second. Using AI tools, it found an issue with the way the delays are being set. I had it write up an issue of what we're seeing. Let me know if there is a different way to handle this. Thanks!

# Robot Description

## Summary

Worker `poll_interval` values above ~1 second are effectively ignored. The exponential backoff logic in `TaskRunner.run_once` caps the exponent at 10, limiting the maximum delay between polls to `0.001 * 2^10 = 1.024 seconds` regardless of the configured `poll_interval`.

## Details

In `task_runner.py`, `run_once` calculates the polling delay with a capped exponent:

```python
# Exponential backoff for empty polls (1ms, 2ms, 4ms, 8ms, up to poll_interval)
# Cap exponent at 10 to prevent overflow (2^10 = 1024ms = 1s)
capped_empty_polls = min(self._consecutive_empty_polls, 10)
min_poll_delay = min(0.001 * (2 ** capped_empty_polls), self.worker.get_polling_interval_in_seconds())
```

The comment says "up to poll_interval", but the backoff plateaus at ~1.024s because `0.001 * 2^10 = 1.024` is always less than any `poll_interval` above ~1 second. The `min()` call never selects `poll_interval`.

## Impact

With workers configured at `poll_interval=5000ms` (5 seconds), we expected ~12 polls/min per worker but observed ~43 polls/min per worker, creating unnecessary load on our infrastructure.

## Expected Behavior

When `consecutive_empty_polls` reaches steady state, the delay between polls should reach the full configured `poll_interval` value.

## Suggested Fix

Either raise the exponent cap so the backoff can reach `poll_interval`, or call `__wait_for_polling_interval()` once the backoff has stabilized (e.g., when `consecutive_empty_polls >= 10`).

## Environment

- `conductor-python` version: 1.3.2
- Python: 3.14