1.1 — fewer round trips on the request path

Two performance changes since 1.0, both aimed at the same cost: producers run
in us-east4 while the ModelQ Redis is in Mumbai, ~271ms away, so every reply
this library waits for before sending the next command lands on a caller's
request path.

- enqueue() now issues its five writes as one pipeline instead of five
  sequential commands. Measured against 5,434 production requests, the old
  path cost a flat 1.355-1.41s regardless of payload size — five round trips.
  The task's own state is also written before the id is advertised on
  ml_tasks, so a worker can no longer pop a task whose task:{id} key does not
  exist yet. (#5)

- Task::getResult() polls once per iteration instead of twice, and backs the
  interval off from 100ms to a 1s ceiling rather than hammering at 100ms for
  the whole wait. A 30s wait costs 9 polls instead of 300. Backoff rather than
  a flat 1s keeps sub-second endpoints fast: realtime_turbo runs in 1.18s at
  p50. (#5)

- Task history no longer stores the request payload a third time. (#4)

No API breaks. POLL_MIN_INTERVAL_US and POLL_MAX_INTERVAL_US are public if you
want the old cadence back.

0.9: O(1) queue-depth counts (getQueuedTaskCount/getProcessingTaskCount)

feat: add markTasksAsError for efficient bulk dead-load draining

Bulk sibling of markTaskAsError that snapshots ml_tasks once and uses a
targeted LREM per task instead of re-scanning the whole list per call, so a
maintenance sweep can drain thousands of leaked queue entries cheaply.
Skips the cancellation flag since callers use it for already-terminal tasks.

feat: add markTaskAsError to fail and drain a task from the queue

When an external system of record (webhook-server timeout sweep, frontend
/fetch give-up) marks a request errored, ModelQ must agree: drain the task
from ml_tasks/queued_requests/processing_tasks and write a terminal failed
state so no worker keeps (re)processing abandoned work. Closes the
queued_requests leak for error/timeout paths (previously only clean
completion removed the queue index).

feat: fully drain a task on removeTaskFromQueue (cancel)

removeTaskFromQueue() only dropped queued_requests when the task was still
present in ml_tasks. A cancelled/given-up task that had already left ml_tasks
stayed in the queued_requests index (inflating queue_num/queue_time) and in
processing_tasks. Now always zRem queued_requests + sRem processing_tasks so a
cancelled task is neither counted nor retried, regardless of where it sits.

fix stuck processing_tasks and queued_requests leak

Mirrors modelq python 1.0.11:
- worker_loop: persist startedAt on Task and status='processing'
  on task:{id} so storeFinalTaskState preserves them
- requeueStuckProcessingTasks: fall back to queued_at when
  started_at is missing (covers workers crashed in SADD→SET window)
- storeFinalTaskState: zRem queued_requests on terminal state

Merge pull request #1 from ModelsLab/fix-task-fetch

fix task details

fix data mapping for payload

fix