chore: Bump taskiq-redis to 1.2.3 and redis to 8.1.0

[Felipe Alvarado (falvaradorodriguez)]

What was wrong? 👾

taskiq-redis 1.2.2 has a race condition in RedisStreamBroker.listen(): the lock check guarding the xautoclaim path is not atomic, so two workers can claim the same pending message and execute the same task twice.

if await lock.locked():
    continue
async with lock:
    pending = await redis_conn.xautoclaim(...)

Reported upstream as taskiq-python/taskiq-redis#123, where the reporter notes it "increases the probability of duplicate task execution beyond the natural at-least-once guarantees of Redis Streams" and that they saw it more than once per minute.

For us this also inflates task volume: a duplicated get_contract_metadata_task double-enqueues the proxy implementation (app/workers/tasks.py:134).

How was it fixed? 🎯

Bump taskiq-redis 1.2.2 → 1.2.3, which makes the lock acquisition and XAUTOCLAIM atomic (PR #126).

1.2.3 requires redis>=8.0.0,<9, so the Python client goes 7.4.0 → 8.1.0. To be explicit: that is redis-py, not the Redis server, which stays on 7.4.10 — the matching version numbers are a coincidence. Verified redis-py 8.1.0 talking to a 7.4.10 server.

The only fallout from the client major was one now-obsolete # type: ignore[misc] in app/datasources/cache/redis.py: redis-py 8.1.0 types hget correctly, and warn_unused_ignores = true turns the leftover ignore into an error.