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

## 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 ` 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 --yaml - < def.yaml`
3. Confirm CLI: `buzz workflows list --channel ` 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 #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: #2385, #4381, #4659 (HTTP bridge `/query` collapses multi-value `#h` to first/lexicographically-first channel). Symptom twin: #4419, #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.