Agent deletion leaves owned workflows live and undeletable

**Describe the bug**
Deleting an agent identity does not disable or remove workflows owned by that agent. The scheduler retains the workflow, but the only identity authorized by `delete_workflow_for_owner` no longer exists, leaving a live workflow that normal clients cannot manage.

A second failure obscures the problem: `buzz workflows delete` signed by a non-owner returns `accepted: true` even though the ownership check prevents deletion and the workflow remains. Relay acceptance is being presented as operation success.

This is a current agent-lifecycle orphan, distinct from the legacy pre-#1369 ID-mismatch orphans in #1593 and the fresh scheduler failure in #4904. The workflow here was valid, scheduled, and manageable until its owning agent was deleted.

**Steps to reproduce**
1. Create an agent and, while operating as that agent, create a scheduled workflow in a channel.
2. Confirm the workflow is listed and scheduled. Production instance reproduced with workflow `b2cc5094-d1e5-4259-9a36-3025678fe2ac` (`OSLead Heartbeat`, every 30 minutes).
3. Delete the owning agent without first deleting its workflow.
4. Run `buzz workflows get --workflow b2cc5094-d1e5-4259-9a36-3025678fe2ac` or list workflows. The workflow still exists and remains scheduled.
5. From another authorized channel member identity, run:

```bash
buzz workflows delete --workflow b2cc5094-d1e5-4259-9a36-3025678fe2ac
```

6. Observe a success-shaped response:

```json
{
"accepted": true,
"event_id": "e9d19eae...",
"message": ""
}
```

7. Get/list the workflow again. It still exists because the signer does not match `owner_pubkey`. The deleted owner cannot return to perform the authorized deletion.

**Expected behavior**
Agent deletion must apply an explicit lifecycle policy to workflows owned by that agent before the identity becomes unavailable. The safest default is to disable them immediately; deleting them or transferring them should require the product's chosen retention/approval semantics. In every case, no owned workflow should continue scheduling as an unmanageable orphan.

A workflow deletion rejected by ownership enforcement must return a failure-shaped result (and a non-zero CLI exit status), not merely report that the deletion event reached the relay.

**Acceptance criteria**
- Deleting an agent discovers all workflow definitions/scheduler rows owned by that agent and disables or removes them before deletion completes.
- No future scheduled run can start for those workflows after the agent is deleted.
- Partial cleanup is surfaced and retryable; agent deletion does not silently succeed while active workflows remain orphaned.
- `buzz workflows delete` distinguishes relay event acceptance from the application-side delete result.
- A non-owner deletion returns a clear ownership error and non-zero exit status, while preserving the existing ownership boundary.
- Integration coverage creates an agent-owned scheduled workflow, deletes the agent, verifies the workflow is absent/disabled and no later run fires, then verifies a non-owner delete cannot produce false success.

**Version and platform**
- Buzz version: 0.5.23
- OS: macOS
- Hosted relay/runtime, reproduced 2026-09-14 UTC

**Logs / additional context**
The ownership check itself is correct and should not be weakened. The lifecycle gap is that agent deletion does not cascade or disable owned workflows before destroying the only signing identity that can manage them.

Related: #1593 documents legacy pre-#1369 workflow rows orphaned by an ID mismatch; #4904 documents fresh scheduler/delete side-effect failures. This report covers a separate, reproducible orphaning path caused by deleting the owning agent.