Pending Cs Tickets

Tickets waiting on Rooster's CS-drafting skill, oldest first -- drained by the same local worker (tools/rooster_worker/worker.py) that already reads /issues/intake/pending and /playbooks/author/pending, in the SAME {"conversations": [{"id": ...}, ...]} shape that worker's fetch_pending already expects (naming kept consistent across surfaces rather than inventing a ticket-specific key for this one).

Registered BEFORE GET /cs/tickets/{ticket_id}/context below, same reason /issues/intake/pending precedes /issues/intake/{conversation_id}/ context: a literal path segment has to be matched before a {ticket_id} one gets a chance to fail UUID validation on the word "pending".

See agent_draft.tickets_awaiting_draft's own docstring for the rule this encodes (once per inbound customer message, never re-fighting a human who just discarded a draft) and gated on the SAME rooster:cs:draft grant as every other CS-drafting route -- reading which tickets need a turn is part of the same drafting capability, not a new one.