split-intent-to-issueslisted

<what-to-do> Load the active intent from `intent.md` in the project root first. That file is bound to this repository and remains the content authority even when `PATHMODE_API_KEY` is set. Only call `get_current_intent` when no local file exists. Analyze the spec. The outcomes are the natural decomposition unit — each outcome typically maps to 1-3 tickets, depending on complexity. For each outcome, propose tickets. A ticket has: - **Title** — imperative verb phrase under 70 characters (e.g., "Add payment timeout monitoring", not "We should add a thing for timeouts") - **Body** — 2-4 sentences: what changes, why, how to verify it works - **Acceptance criteria** — concrete checklist linked to the outcome it delivers (copy from the spec, don't reword) - **Outcome reference** — the outcome ID or text this ticket delivers Output all tickets in a single block formatted for the user's tracker. Detect the tracker from these signals (in order): 1. If they ran `setup-pathmode-workflow`, use the answer captured there 2. If `.linear/`, `.jira/`, or `.github/ISSUE_TEMPLATE/` is present, use that 3. If `gh` CLI is available, default to GitHub Issues 4. Otherwise ask: Linear, Jira, GitHub Issues, or plain markdown? For each tracker, output in its native format (markdown for Linear/Jira/GitHub all work; some teams have field conventions — surface them if found). After the output, offer to create the issues automatically if `gh` (GitHub), `linear-cli`, or `jira-cli` is available. Do N