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

## 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

```yaml
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:
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

```bash
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

```bash
buzz workflows approve --token --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 ` 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

```bash
# 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

```bash
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/`. 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.

Start by reproducing the minimal workflow with `buzz workflows trigger`, then inspect the `request_approval` workflow action and the CLI paths for `workflows approve`, `feed get --types needs_action`, and `workflows runs`. Trace why the approval step creates no token or event and verify that a triggered workflow exposes a resolvable approval, accepts approval, and advances to the next step.

Written by the indexing model from the issue text.