fix(transcoder): ack only after successful metadata ready update

[SlavaKuntsov]

Closes #50

Summary

• process_message now raises when the final update_status(video_id, "ready", ...) fails, so the transcoder consumer no longer basic_acks a message whose video would stay «processing» forever with no retry (issue P1 transcoder: ack message only after successful metadata update #50, from review M7).
• The on_message closure in main() is extracted to a module-level handle_message (behavior-identical) so retry/DLQ logic is testable: ack only after successful processing; on failure republish to video.uploaded.retry with incremented x-retry-count (TTL dead-letters back to the main queue); after MAX_RETRIES mark failed + basic_nack(requeue=False) → DLX → DLQ.
• Raw-object cleanup still happens only after metadata confirms ready.

Acceptance criteria

• ack только после успешного update_status("ready")
• иначе retry-очередь / basic_nack(requeue=False) → DLX/DLQ
• тест «metadata упал → ретрай, не ack»

Verification

• uv run --project services/transcoder pytest services/transcoder/tests -q — 25 passed
• uv run --project services/auth pytest services/auth/tests -q — 18 passed
• black --check, flake8, mypy (transcoder) — clean
• make e2e — not run (requires full docker compose stack)

Remaining risks

• Metadata-only failure re-runs the full pipeline on retry even though renditions are already uploaded (bounded by MAX_RETRIES=3, re-uploads idempotent per rendition key) — follow-up candidate for a ready-PATCH-only retry path.
• Pre-existing (unchanged): poison messages (invalid JSON) are acked and dropped rather than dead-lettered.