fix(task-board): don't refire a Jira-synced column's automation when the column didn't change

[pedrofrxncx]

Source: hardening follow-up to #6800 ("run a column's rule when a card lands there, however it moved") — the fix that landed there for the board's own drag path (TASK_BOARD_ITEM_UPDATE) was never mirrored onto the Jira sync's leg of the same shared runColumnAutomation.

Bug: the Jira pull (apps/api/src/jira/sync.ts) re-fires an issue's landing column's automation on statusChangedOnJira — i.e. whenever the Jira status literal changed — not on whether the card's board column actually changed. Since statusMapping (and a mirrored Jira board) can map several distinct Jira statuses onto one board column, an issue flipping between two such statuses (e.g. "In Review (Dev)" → "In Review (QA)") never moves the card's column at all, yet still re-triggers runColumnAutomation. runColumnAutomation is a no-op on an already-owned card, but a card a prior run un-delegated (a quota rejection, a burned reviewer retry — see unassignSuperAgent) is unassigned again, so the next same-column Jira ping-pong re-claims it and dispatches a brand-new agent run for a card that, from the board's perspective, never left its column. The web/drag path already guards this exact case with previous.status !== item.status (update.ts:528-537); the Jira leg had no equivalent.

Fix: extracted the guard as a pure, unit-tested predicate triggersColumnAutomation({ previousStatus, newStatus, isRescan }) (same pattern as this file's existing rewritesStatus/rewritesSprint) and used it at the Jira sync's maybeAutoDelegate call site, gating on the card's actual board-column transition instead of the raw Jira status diff. The create-path call site is untouched — a brand-new card is a landing by definition.

Regression test: apps/api/src/jira/sync.test.ts — "does not fire when two Jira statuses map onto the same board column" encodes the old (broken) behavior inverted, plus a same-shape positive case and the pre-existing rescan case.

To verify: bun test apps/api/src/jira/sync.test.ts

Checks run locally: bun run fmt, cd apps/api && bunx tsc --noEmit (clean), the targeted test file above (34 pass), bunx oxlint apps/api/src/jira/sync.ts apps/api/src/jira/sync.test.ts (0 warnings/errors). Full CI validates the rest.

---

Summary by cubic

Fixes the Jira sync re-firing a column's automation when the Jira status changed but the card's board column didn't. Multiple Jira statuses can map to one board column, so an issue pinging between two such statuses (e.g. "In Review (Dev)" → "In Review (QA)") previously re-triggered runColumnAutomation, re-claiming an un-delegated card and dispatching a fresh agent run for a card that never left its column.

• Extracts the guard as a pure, unit-tested triggersColumnAutomation({ previousStatus, newStatus, isRescan }) predicate, mirroring the web/drag path's existing check.
• Uses it at the Jira sync's maybeAutoDelegate call site; the create path is untouched since a new card is a landing by definition.
• Adds regression tests for the same-column case, a positive column change, and rescans.

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