Prevent stale queue snapshots from regressing workflow completion state

[JPPhoto]

Summary

Fix a race where fast workflow runs could stay visible as working after the queue had already drained.

This PR adds a per-item status_sequence to queue items and queue_item_status_changed events, persists it in invokeai/app/services/shared/sqlite_migrator/migrations/migration_28.py, and uses it in invokeai/frontend/web/src/features/controlLayers/components/StagingArea/state.ts to ignore stale queue snapshots that arrive after newer status updates. It also updates invokeai/frontend/web/src/services/events/setEventListeners.tsx so queue caches carry the new sequence immediately from socket events.

Related Issues / Discussions

QA Instructions

1. Back up your database or run with an in-memory database; this PR involves a DB migration.

2. Build the frontend as normal.

3. Run backend tests:
   pytest tests/test_session_queue.py tests/app/services/session_queue/test_session_queue_clear.py tests/app/services/session_queue/test_session_queue_status_sequence.py tests/app/routers/test_session_queue_sanitization.py tests/test_sqlite_migrator.py

4. Run the staging area frontend tests:
   cd invokeai/frontend/web && ./node_modules/.bin/vitest run src/features/controlLayers/components/StagingArea/state.test.ts

5. Try reproducing manually by running a very fast workflow (with one Integer Primitive node, for example) and confirming the staging area does not remain stuck in a pending or working state after completion.

Merge Plan

This touches queue event payloads and adds a DB migration in invokeai/app/services/shared/sqlite_migrator/migrations/migration_28.py, so it should be rebased cleanly before merge.

Checklist

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

[lstein]

@JPPhoto The last commit fixed the "stuck" issue I'd found in fast-running workflows, and I'ved this PR

I did run a code review with Claude Code and it had a few very minor suggestions. They seem reasonable, but I'll leave it up to you whether you wish to implement them before the merge. I'll check in again tomorrow to see what you prefer.

Blocking issues: None.

Non-blocking suggestions:

1. session_queue_common.py:222 — status_sequence Pydantic default is None but DB default is 0; a one-line comment explaining the fallback-for-pre-migration
   intent would help future readers.
2. state.ts:152 — _pruneSeenItemOrdering intentionally drops tracking for vanished items; a comment noting this is the eviction trade-off (vs. unbounded
   memory growth) would clarify intent.
3. migration_30.py has no dedicated test like test_migration_27_creates_users_table. The generic idempotency test covers the framework but not the backfill
   path. Low risk, but a focused test would strengthen guarantees.
4. test_session_queue_status_sequence.py:76 — existing cancel test uses never-dequeued items (seq goes to 1). A complementary dequeue-then-cancel case
   (verifying 1 → 2) would prove the counter continues rather than resets. The lifecycle test already exercises this path, so it's a mild gap.
5. _shouldAcceptQueueItem equal-sequence tiebreaker falls through to rank comparison; worth a comment calling out that terminal-vs-terminal at same sequence
   will accept the later arrival (edge case that shouldn't occur but is handled sensibly).

Positive notes:

• COALESCE(status_sequence, 0) + 1 is atomic and correctly handles both NULL and 0 in one expression.
• Dual-track ordering (_seenItemStatusSequences + _seenItemStatusRanks fallback) cleanly handles missing-sequence events.
• ?? undefined (not || undefined) correctly preserves status_sequence = 0.
• Event handler records ordering before early-returns, so skipped events still advance the counter.
• Schema.ts asymmetry (event field required, queue-item field optional) matches backend Pydantic correctly and appears properly auto-generated.

[JPPhoto]

@lstein Glad that fixed it. Those comments are now in the code and I've added the test case in test_session_queue_status_sequence.py. I don't think the migration needs a test.