fix(session queue): count only rows actually transitioned by a bulk cancel

[lstein]

Summary

Follow-up to #9263, addressing the duplicate bulk-cancel counting deferred in @JPPhoto's 2026-07-25 review:

_cancel_in_progress_matching() counts an item whenever _set_queue_item_status() returns an object whose status is canceled. Two concurrent bulk cancellations can both select the same in-progress row; the first transitions it, while the second receives the already-terminal canceled row and counts it again despite making no transition.

• The terminal guard is now part of the cancel UPDATE statement itself: _transition_queue_item_status() performs UPDATE ... WHERE item_id = ? AND status NOT IN ('completed','failed','canceled') and reports via cursor.rowcount whether THIS call performed the transition. _set_queue_item_status() is a thin wrapper preserving its existing contract.
• _cancel_in_progress_matching() counts only actual transitions, so two racing bulk requests each report a disjoint set of canceled items.
• Side benefit: the previous SELECT-then-UPDATE window in _set_queue_item_status (a row could turn terminal between the read and the write) is gone.

Test

test_concurrent_bulk_cancels_count_each_item_once uses a barrier to hold two cancel_by_batch_ids requests after their item-id SELECTs (both have selected the same two in-progress rows) and asserts the combined canceled count is exactly 2 — under the old code it was 4. Verified the test fails against the previous counting logic.

Merge order

Stacked on #9263 — this branch contains the multi-GPU branch's commits. Draft until #9263 merges; will then rebase onto main and mark ready for review.

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

🤖 Generated with Claude Code

[lstein]

Rebased onto the current #9263 head (272a2ef2ea). The rebase crossed #9355's single-transaction restructure of _set_queue_item_status, so the fix was re-implemented on the new shape: the terminal guard + UPDATE were already atomic in one transaction; what was missing was exposing WHO transitioned the row. _transition_queue_item_status now returns that bool and the bulk counter uses it. A fresh-context adversarial review of the resolution found no behavioral regressions across all seven callers; the docstring now records that the atomicity comes from SqliteDatabase's process-wide lock, not the SQL. 88 session-queue tests green, barrier test 15/15.

[JPPhoto]

Approved!

You might want to consider guarded SQL UPDATE plus cursor.rowcount; the current guarantee relies on shared SqliteDatabase._lock.