Desktop Workflows list empty on hosted community (0.5.3) while kind 30620 + schedule still live

[meleantonio]

Bug Description

Buzz Desktop Workflows global view shows empty / "No workflows yet" even when:

• Settings → Experiments → Workflows is on
• the signed-in identity is a channel member
• buzz workflows list --channel <uuid> returns the definition
• the scheduled workflow still fires (send_message wake lands in-channel)

This is the same user-visible failure class as #4419 / #2385 / #4659 (multi-value #h / HTTP bridge /query scoping). Filing with a concrete hosted-community repro so it is not only tracked from self-hosted reports.

Steps to Reproduce

1. Hosted Buzz community; Desktop with Workflows experiment enabled.
2. Create (or already have) a channel-scoped schedule workflow, e.g. kind 30620 on channel build-autonomously via Desktop create or:
   buzz workflows create --channel <channel-uuid> --yaml - < def.yaml
3. Confirm CLI: buzz workflows list --channel <channel-uuid> returns the row (example id e46e46f6-73af-44dd-9b76-a52372d9b627, name "Hermes Daily Autonomous Build", cron 0 3 * * *).
4. Confirm schedule can fire (manual trigger / wait for cron) — wake message posts in-channel.
5. Open Desktop global Workflows route (not a channel thread) and refresh.

Expected Behavior

Global Workflows list shows every workflow for channels the current identity is a member of, so owners can inspect/edit/delete without CLI.

Actual Behavior

List stays empty ("No workflows yet" / blank). Definition remains on the relay; schedule continues. UI cannot manage the live workflow.

Environment

• OS: macOS
• Buzz Desktop: 0.5.3 (also reported on 0.5.4 in HTTP bridge /query silently scopes multi-value #h filters to a single channel (breaks desktop Workflows list) #4659)
• Relay: hosted Buzz community (not only self-hosted)
• Feature flag: Workflows experiment enabled
• Client path: Desktop get_channels_workflows batched multi-#h query over member channels

Additional Context

• Related root-cause writeups: relay: multi-value #h filters collapse to lexicographically-first channel (Workflows overview shows empty) #2385, POST /query returns events from only one channel when a filter has multiple #h values #4381, HTTP bridge /query silently scopes multi-value #h filters to a single channel (breaks desktop Workflows list) #4659 (HTTP bridge /query collapses multi-value #h to first/lexicographically-first channel). Symptom twin: Desktop Workflows view shows empty despite channel workflows returned by relay #4419, [BUG]Workflow is created and runs, but is missing from the Workflows list on a self-hosted relay #2373.
• Workaround: treat CLI / buzz workflows trigger as source of truth; avoid thrash-recreating definitions from Desktop while the list is blank (duplicates accumulate because create succeeds and list never shows them).
• Separate product pitfall (not this bug): scheduled send_message is a wake ping; Desktop ACP owner-only agents ignore non-owner workflow-bot pings. That is agent allowlist behavior, not the empty list.

Happy to add redacted request/response pairs for POST /query with single vs multi #h if useful.