Delete service channels from the catalog, attached or not

[edwin-zvs]

Problem

Two things were wrong with channel deletion:

1. "Delete" did not delete. delete_channel forwarded straight to detach_channel, which removes the channel from the service definition but leaves it in the shared catalog. The TUI then reported "Channel `x` deleted and withdrawn." while the channel was still sitting there as an available row.
2. An unattached channel could not be deleted at all. open_edit_service_channel returned false unless the channel was attached to the current service, so d (and the editor's C-d) was a silent no-op on exactly the available rows a user would want to clean up.

Change

Daemon (crates/daemon/src/service.rs). delete_channel now owns its semantics instead of delegating:

• channel not in the catalog → channel \x` not found in catalog`;
• attached to another service → channel \x` is attached to service `owner`; delete it from there` (deletion must not steal another service's channel);
• attached to this service → detach from the definition and drop the catalog entry;
• attached to nothing → drop the catalog entry.

Both the service definition and the catalog are persisted. The SERVICE_CHANNEL_DELETE dispatch is unchanged, so deletion still withdraws the endpoint.

TUI (crates/cli/src/app/service_dialog.rs, ui.rs). d on the channel list arms the delete confirmation for an unattached catalog row too. Editing is still restricted to channels attached to this service — the delete path is the only one that admits an unattached row. Channels owned by another service are refused with an explanatory note instead of silence. The confirm prompt and the result note say "catalog" for an unattached channel rather than claiming a withdrawal that never happened, and the existing refresh_services re-reads the catalog so the row disappears. The edit-mode footer now mentions d delete channel.

The diff is deliberately localized to deletion — no changes to field indices, the field list, or channel-list navigation.

Tests

• cargo test -p construct-daemon --lib — 530 passed. New deleting_a_channel_removes_it_from_the_catalog covers all four branches; service_put_preserves_channels_and_channel_crud_rotates_credentials now also asserts the catalog is empty after delete; channel_catalog_migrates_and_controls_exclusive_attachments was asserting the old "delete leaves it in the catalog, detached" behavior and now calls detach_channel for that step, which is what it was actually testing.
• cargo test -p construct-cli — 1318 passed. New unattached_catalog_channels_can_be_deleted_but_owned_ones_cannot.

No spec file added (a sibling branch is adding one in this area).