ci: add issue triage workflow with manual dispatch

[kraenhansen]

New issues should reach Cursor for triage automatically, and it must be possible to re-run triage on an existing issue without closing and reopening it.

Merging this PR will:

• Add a workflow that posts the issue number to the Cursor triage webhook when an issue is opened.
• Expose the same workflow as a manual run taking an issue_number input.

---

Additional context intended for coding agents and bots

How the issue number is resolved

Both triggers feed one step. github.event.issue.number is set for the issues event and empty for workflow_dispatch, so ${{ github.event.issue.number || inputs.issue_number }} picks whichever is present. It is passed through a step-level env rather than interpolated directly into the shell script, which keeps workflow expressions out of the executed command.

Secrets required

• ISSUE_TRIAGE_CURSOR_WEBHOOK_URL
• ISSUE_TRIAGE_CURSOR_WEBHOOK_AUTHORIZATION_HEADER

Both must exist at the repository or organization level. A manual run is the cheapest way to confirm they are configured.

Known rough edges

• The workflow display name still reads "Trigger Cursor on Issue Creation", which undersells it now that it can be dispatched by hand. Left as-is deliberately; happy to rename if a reviewer prefers.
• No permissions: block is declared, so the job gets the repository default. The job never uses GITHUB_TOKEN, so permissions: {} would be a safe tightening if the repo wants it.

Test plan and verification

• Workflow file parses as valid YAML.
• npx prettier --check .github/workflows/triage-issue.yml passes.
• Shell body renders as {"issue_number": 1234} for a given issue number.
• Manual workflow_dispatch run against a real issue, once merged to the default branch. GitHub only offers the Run workflow button for workflows present on the default branch, so this cannot be exercised from the branch.

🤖 Generated with Claude Code

[kraenhansen]

Moving away from this approach.