feat(queue): show user/total pending jobs in multiuser mode badge

[Copilot]

Summary

The queue badge now displays "X/Y" format in multiuser mode, where X is the authenticated user's pending jobs and Y is the total across all users. Single-user mode shows total count only. The badge updates in real-time when any user enqueues or completes jobs.

Backend:

• Extended SessionQueueStatus with optional user_pending and user_in_progress fields
• Added user_id parameter to get_queue_status() method
• SQLite implementation queries user-specific counts within same transaction as total counts
• API endpoint passes authenticated user ID automatically

Frontend:

• QueueCountBadge detects multiuser mode via authentication state
• Displays "X/Y" when user counts available, falls back to total count otherwise
• Extracted hasUserCounts() and getBadgeText() helpers for clarity
• Real-time updates: Socket event handlers invalidate SessionQueueStatus cache on queue changes, triggering automatic refetch with user-specific data

Badge display logic:

• No pending jobs → hidden
• Single-user with jobs → shows total (e.g., "3")
• Multiuser with user jobs → shows "X/Y" (e.g., "2/5")
• Multiuser with only other users' jobs → shows "0/Y" (e.g., "0/3")

Real-time behavior:
When User B enqueues a job, User A's badge immediately updates to reflect the new total without requiring a page reload.

Related Issues / Discussions

Addresses the enhancement request for multiuser queue visibility.

QA Instructions

1. Single-user mode: Verify badge shows total count or is hidden when no jobs
2. Multiuser mode:
   • Log in as User A, enqueue jobs, verify badge shows "X/Y"
   • Log in as User B, enqueue jobs, verify User A's badge immediately updates to show correct counts without reload
   • Verify user with no jobs sees "0/Y" when other users have jobs
3. Real-time updates: Confirm badge updates instantly when any user starts/completes jobs

Merge Plan

None required. Changes are backwards compatible.

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)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[enhancement]: In multiuser mode, distinguish between user's pending jobs and all pending jobs</issue_title>
<issue_description>### Is there an existing issue for this?

• I have searched the existing issues

Contact Details

No response

What should this feature add?

When there are pending generation jobs in the queue, the Queue menu button at the top of the left panel (three horizontal lines) shows a yellow badge with the number of pending jobs. This is fine in single-user mode, but in multi-user mode it does not distinguish between the current user's pending jobs and the total number of pending jobs (which may include other users' queue items). In multiuser mode, this badge should be changed to read "X/Y" where X is the number of the current user's pending jobs, and Y is the total number of all user's jobs, including the current user's.

Here are the scenarios:

• Single user mode, no pending jobs: don't show the badge
• Single user mode, one or more pending jobs: show the total job count
• Multiuser mode, no pending jobs: don't show the badge
• Multiuser mode, current user with one or more pending jobs: show X/Y, where X is user's pending jobs and Y is total number of jobs
• Multiuser mode, current user with no jobs, but at least one pending job from another user: show 0/Y, where Y is total number of jobs.

Alternatives

No response

Additional Content

No response</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes [enhancement]: In multiuser mode, distinguish between user's pending jobs and all pending jobs #42

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[lstein]

@copilot I am not seeing the expected behavior. Scenario:

1. I start a generation for user A -- The badge displays "1"
2. I start a generation for user B -- The badge displays "2", A's badge doesn't change
3. I reload A -- The badge displays "1/2"
   So I think that updates aren't having an immediate effect on the badge. Perhaps it would be better to base the badge display on the queue listing (displayed in the Queue tab), which is being updated in real time.

[Copilot]

@copilot I am not seeing the expected behavior. Scenario:

1. I start a generation for user A -- The badge displays "1"
2. I start a generation for user B -- The badge displays "2", A's badge doesn't...

Fixed in commit 69265e6. The issue was that socket events (queue_item_status_changed and batch_enqueued) were directly updating the cached queue status with data from the server, which didn't include user-specific counts. Now these events invalidate the SessionQueueStatus cache tag, triggering an automatic refetch with the current user's credentials. This ensures the badge updates in real-time with the correct "X/Y" format for all users.

Expected behavior now:

1. User A starts generation → badge shows "1" (or "1/1" in multiuser mode)
2. User B starts generation → User A's badge immediately updates to "1/2" (without reload)
3. Queue status refetches automatically on all queue events

[lstein]

Working as requested.