to-tickets: parent issue remains pickable after decomposition

## Description `to-tickets` breaks a parent issue into child issues but does not mark the parent as "don't work on this directly". After creating children, the parent remains in its original triage state (e.g. `ready-for-agent`) and can be picked up by any agent the same as before — defeating the purpose of breaking it down. ## Steps to reproduce 1. Create a PRD issue as a result of a grilling session 2. Run `to-tickets`, ask to split one of the issues into 2+ smaller ones 3. Children are published correctly with `## Parent` and `## Blocked by` 4. The parent issue is left untouched — no new labels, no "blocked by children" note, no status change 5. Another session picks up the parent (it still has `ready-for-agent`), implements everything in one go, and the children become orphans ## Expected behavior After `to-tickets` creates children, the parent should be protected from accidental implementation: - **Either:** the parent's triage label is changed (e.g. to `epic` or `needs-triage`), and a `> [!WARNING]` note is added to the body: "This issue is broken down into #N, #M, #K — do not implement directly" - **Or:** the `## Parent` field in children is treated as a reverse dependency, and `to-tickets` itself updates the parent body to list its children as blockers ## Why it matters The whole point of `to-tickets` is decomposing work so pieces can be implemented independently. If the parent remains pickable, agents routinely bypass the decomposition and implement the whole epic at once — leaving child issues as unclosed orphans and wasting the decomposition effort.