Workflows: fresh scheduled triggers never fire and delete returns accepted while definition persists

## Summary

Fresh scheduled workflows are accepted and listed but never fire. Deleting the same fresh workflow returns `accepted:true`, yet the workflow remains listed and active-looking.

This is a silent-success failure in both directions: create/delete report success while the requested scheduler/delete side effect does not happen.

This is **not limited to legacy pre-#1369 orphan rows** described in #1593. The reproduction below used a newly created workflow on the current hosted relay/runtime.

## Reproduction 1 (2026-08-03 UTC)

Two fresh schedule probes were created with `accepted:true` in a quiet test channel:

```text
cron "53 15 * * *" -> no message by 15:56 (4.5 minutes past the due time)
cron "* * * * *" -> no messages by 16:00 (about four due slots)
```

The every-minute probe removes timezone interpretation as an explanation. Neither fresh definition fired.

## Reproduction 2 (2026-08-04/05 UTC)

Created fresh workflow `7ff24431-aef7-40a6-b3a3-8c5af812e44d` at `2026-08-04T23:54:19Z`:

```yaml
name: step0-fresh-cron-canary
description: Fresh five-minute scheduler verification
trigger:
on: schedule
cron: "*/5 * * * *"
steps:
- id: canary_fire
action: send_message
text: "CANARY CRON FIRE "
```

Observed:

- Watched for 14+ minutes (at least two due five-minute slots): zero token-bearing messages.
- Re-read channel history through `2026-08-05T15:23:42Z`: zero token hits.
- Ran `buzz workflows delete --workflow 7ff24431-aef7-40a6-b3a3-8c5af812e44d`.
- CLI output:

```json
{"accepted":true,"event_id":"625d11e16eab912875593a6398bfa25a61b1c892c609404f2a3c0139a1d4e6f1","message":""}
```

- An immediate `buzz workflows list` still returned both `7ff24431…` and an unrelated workflow.
- Rechecked immediately before filing: `7ff24431-aef7-40a6-b3a3-8c5af812e44d` still appears in `workflows list` with the original YAML.

## Expected behavior

- A fresh scheduled workflow fires on due cron ticks.
- Deletion either removes the definition and scheduler row or returns a non-success outcome explaining why it did not.
- `accepted:true` should not be the only signal when the server-side side effect fails.

## Actual behavior

- Definition create is accepted and visible, but scheduled action never runs.
- Delete is accepted, but the definition persists.
- No error is surfaced to the caller.

## Impact

Scheduled safety checks and agent wakeups appear configured but silently never execute. Operators also cannot reliably clean up the inert definitions because delete claims success without changing state.

## Suggested diagnostics/fix

1. Return a structured execution result for workflow create/delete side effects, separate from event acceptance.
2. On delete, reread the targeted workflow and fail if it still exists.
3. Log workflow ID, next due time, scheduler registration, tick, action result, and delete-row count.
4. Add an integration test that creates an every-minute workflow, observes a fire, deletes it, and proves no later fire plus absence from list/storage.

Related: #1593 covers legacy orphan rows and already notes silent-success deletion; this report demonstrates the same externally visible failure on a fresh current workflow. #4696 covers a separate Desktop workflow-list/query problem.