Cue dashboard Run Now only fires the first subscription when an agent has multiple

[scriptease]

Summary

In the Cue modal's Sessions Table, when an agent has multiple subscriptions in its cue.yaml, clicking Run Now only fires the first subscription. There is no per-subscription Run Now control surfaced — or if there is, only the first one is wired up. This makes Run Now unusable as a bootstrap mechanism for any subscription other than the first declared in YAML.

Repro

1. Configure two subscriptions on the same agent's cue.yaml:

   subscriptions:
     - name: "daily end-of-day summary"
       event: time.scheduled
       schedule_times: ["18:00"]
       prompt: playbooks/end-of-day.md
   
     - name: "research queue"
       event: task.pending
       watch: "research.md"
       poll_minutes: 1
       prompt_file: .maestro/prompts/cue-research.md

2. Open the Cue modal (Option+Q) and locate this agent's row in Sessions With Cue.

3. Click Run Now.

4. Observed: only daily end-of-day summary fires (the first in YAML order). research queue is never triggered.

5. Expected: either each subscription has its own Run Now, or the user is offered a picker, or all subscriptions fire.

Why this matters

Run Now is documented as the escape hatch for the task.pending first-scan seeding behavior (see #865) and for cases where a user wants to manually verify a subscription works. Both use cases collapse if Run Now silently fires only the first subscription — the user is left thinking the other subscription is broken when actually it was never asked to run.

It also conflates the session-level action (open the agent, etc.) with the subscription-level action (fire this one trigger), which the docs treat as separate concerns:

"Each subscription row in the Sessions Table has a Run Now button that manually triggers it, bypassing its normal event conditions."

The "subscription row" wording reads as if there is one button per subscription, but in practice the UI renders only one Run Now per session row.

Suggested fixes

1. UI fix (preferred) — render Run Now per subscription, not per session. Each subscription is independently runnable. Backed by the existing IPC handler cue:triggerSubscription which already takes subscriptionName: string (src/main/ipc/handlers/cue.ts:143).
2. Picker fallback — if the row stays single-button, on click open a small popover listing subscription names and let the user pick which to fire.
3. Last resort: fire all — clicking Run Now fires every subscription in the YAML. Less precise but at least nothing is silently skipped.
4. CLI parity — maestro-cli cue trigger <name> already targets a specific subscription by name; the dashboard should not be less capable than the CLI.

Workaround today

maestro-cli cue trigger "research queue" correctly fires a non-first subscription. Use this until the dashboard supports it.

Related

• task.pending: first-scan seeding never fires, even when tasks already exist #865 — task.pending first-scan seeding (Run Now is the documented escape hatch)
• Cue dashboard ignores agents with valid cue.yaml until they're opened in the UI #866 — dormant agents not visible in dashboard
• Multiple agents sharing a project root run every Cue subscription N times — no way to designate an owner #867 — multiple agents sharing a project root run every subscription N times