request_approval silently no-ops on buzz workflows trigger — no token/card; result step never runs

[Svpplements]

Describe the bug

The workflow step action: request_approval produces zero resolvable approval surface (no token, no card, no result step) when triggered via buzz workflows trigger. The workflow's send_message step fires correctly, but the workflow silently stalls at the request_approval step and never reaches subsequent steps.

This makes the workflow approval card decorative — the YAML defines an approval gate, but no approval is ever created or surfaced for resolution.

Steps to reproduce

1. Create a minimal parameterless workflow

name: gate-approval-minimal
description: Minimal test — no template vars, just send + request_approval
trigger:
  on: webhook
steps:
  - id: notify
    action: send_message
    text: "Test approval card — no template vars"
  - id: approval
    action: request_approval
    from: <trent-pubkey-hex>
    message: "Test: approve or deny this card"

Created workflow ID: 9041f4b0-4e48-4553-9b92-e450c0831420
Channel: #command-center (fd688946-bf0e-4a70-bc9d-f51bd19736aa)
Relay: wss://suppvault.communities.buzz.xyz

2. Trigger it

buzz workflows trigger --workflow 9041f4b0-4e48-4553-9b92-e450c0831420

3. Observe

• Step notify (send_message) → ✅ fires. Kind 9 message appears in-channel with buzz:workflow tag.
  • Event IDs: 29c2d759…, 57ea92b1… (content = static "Test approval card — no template vars")
• Step approval (request_approval) → ❌ fails silently. No approval event of any kind is created. No token returned or discoverable.
• Step after approval → ❌ never reached. The workflow stalls at step 2.

4. Attempt to resolve an approval

buzz workflows approve --token <run_id-or-any-uuid> --approved true
# → relay error 400: invalid: approval not found

The run_id returned by buzz workflows trigger is not an approval token, and no approval token is returned or discoverable anywhere.

Expected behavior

request_approval should create a resolvable approval surface when triggered via buzz workflows trigger:

1. Return an approval token in the trigger response (alongside run_id), or a documented discovery path for the token
2. Create a visible approval event/card (kind is product's choice) that Desktop and CLI can resolve
3. Surface pending approvals in buzz feed get --types needs_action (or document the alternate surface)
4. Allow buzz workflows approve --token <token> to resolve them
5. Advance the workflow to the next step after resolution

Version and platform

• Buzz version: Desktop 0.5.5
• Relay: wss://suppvault.communities.buzz.xyz
• OS: macOS 26.5.2

Logs / additional context

Confirmation that request_approval creates nothing

# After triggering, query the channel for approval events:
buzz messages get --channel fd688946-bf0e-4a70-bc9d-f51bd19736aa --kinds 39001,39002 --limit 10
# → only channel-metadata events (member roster), which predate the trigger

# Feed also shows nothing:
buzz feed get --types needs_action
# → []

Independent of template interpolation

This is a separate defect from template variable interpolation. The minimal workflow above has no template variables — request_approval still no-ops. (Template interpolation is filed separately.)

workflows runs returns empty

buzz workflows runs --workflow 9041f4b0-4e48-4553-9b92-e450c0831420
# → [] (always — run history is not exposed as events)

This makes it impossible to inspect run state or extract approval tokens programmatically.

webhook_secret returned on create but HTTP endpoint RBAC-denied

The workflow create response includes a webhook_secret, suggesting an HTTP endpoint at /webhook/<workflow_id>. However, all HTTP POST attempts return 403 RBAC: access denied (not 404) without Nostr-signed auth. This path is undocumented for agents.

Impact

This blocks replacing a 60-second launchd poller (trent-gate-pusher) with an event-driven Buzz workflow. The signed-event approval card is the load-bearing feature — without it, the workflow is notification-only with no gate enforcement, which is strictly worse than the existing push-notification path.