feat(jira): a status rule can continue the issue's pull request

[viktormarinho]

What

The "continue the pull request the issue already carries" option existed only on the manual run. The column automation always started fresh, so a card a reviewer sent back to the implementing column got a second pull request for the same change.

A status rule now has a continuePr flag, saved with the rule and shown as a checkbox on its card in Settings → Jira. When on, every run the rule starts:

1. Reads the issue's web links and keeps the newest pull request per repository (pullRequestsFromLinks, unchanged).
2. Asks the provider for each one's state and head branch. Closed or merged ones are skipped: a person ended those on purpose.
3. If at least one is open, pins the sandbox to the first one's branch and leads the prompt with "continue this pull request". If none is open, the run starts fresh, exactly as before.

So "is this a re-execute" is answered by the issue's state, not by the direction of the move. A first entry carries no pull request and starts fresh; a card bounced from review carries the reviewed one and continues it. The flag only says on which statuses to look. It stays off on a review status, or that run would be pinned to the pull request it is about to judge.

Issues that span repositories

Previously a reciprocal change with a pull request in each storefront resolved to nothing and re-implemented from scratch. Now the first open pull request is the pinned branch and the rest are others: the prompt names each with its repository and head branch and tells the run to git fetch and git checkout it after cloning that repository, and to update none if it cannot update all. Both prompt builders (sandbox and Decopilot) get the same lead. The manual continuePr path uses the same resolution, so it gains multi-repo continuation too.

Changes

• Migration 220: org_jira_column_automations.continue_pr boolean not null default false.
• Storage, JIRA_AUTOMATION_LIST / JIRA_AUTOMATION_UPSERT, web hook and tool contracts carry the flag. Contracts hand-edited, same reason as feat(jira): one run across several issues, with issue-scoped Jira tools #7371.
• openPrForIssue returns the primary plus others instead of bailing on several repositories.
• triggerRunForTransition resolves the pull request when the rule says so.
• Settings UI: a checkbox under each rule's prompt, saved on toggle, with a help line explaining the heuristic. No screenshot: no local Studio running.

Testing

• New prompt test: a pull request in a second repository is named with its branch and the all-or-none instruction.
• Real-Postgres storage test extended: the flag round-trips through upsert and get.
• bun run check, bun run lint (0 warnings), knip clean. Unit suites under apps/api/src/jira, apps/api/src/tools/jira and the task-board prompt tests pass. Migration and storage integration tests need a local Postgres this environment does not have.

---

Summary by cubic

Jira status rules can now continue the issue's existing pull request instead of opening a new one. Previously every rule-triggered run started fresh, so a card a reviewer sent back to the implementing column got a second pull request for the same change.

Adds a per-rule continuePr flag, saved with the rule and shown as a checkbox in Settings → Jira. When enabled, the run resolves the issue's open pull requests from its web links and pins to the first open one; if none are open, it starts fresh as before. For issues spanning repositories, the first open pull request is the pinned branch and the others are named in the prompt with their branches. The flag is off by default, so existing rules keep their current behavior. Migration 220 adds continue_pr to org_jira_column_automations. Keep the flag off on review statuses, where the run would otherwise pin itself to the pull request it is meant to judge.

^{Written for commit b2c4ee2. Summary will update on new commits.}