feat: expose per-task queue and run timings to the producer

[adhikjoshi]

Why

A generation API answered a request in 37.7s while the only timer in its response read generationTime: 5.55. That timer starts after the task is enqueued, so it hid the 30s the HTTP handler had already spent, and it merged queue wait into the same number as the run. Nothing in the response could account for the missing 32s.

ModelQ already records created_at / queued_at / started_at / finished_at and persists them in the terminal task_result: blob — but a producer could not read any of it:

1. The task decorator wrote created_at/queued_at into the dict it pushed to Redis and never onto the Task object it handed back, so task.queued_at was always None.
2. get_result() copied only result and status off the terminal blob and dropped the run timestamps.

What

• Mirror the enqueue stamps onto the Task the producer receives.
• get_result() absorbs the terminal blob's timestamps before it can raise, so a failed or cancelled task still reports where its time went — the case that most needs the split.
• New Task.stage_timings() → {queue_time, run_time, total_time}.

A stage that cannot be measured is omitted, not zeroed. A fabricated 0.0 reads as "instant" and would hide the very stall this exists to expose.

Compatibility

Additive. A result blob from an older worker leaves the timestamps the producer already holds untouched, and stage_timings() returns {}. Callers that never look at the timestamps are unaffected.

Tests

tests/test_stage_timings.py — 5 tests covering the queue/run split, the omit-don't-zero rule, timestamps surviving a failed task, and an older worker's blob not clobbering what the producer holds.

Mutation-tested: with both source changes reverted, all 5 go red. Full suite: 107 passed.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}