Add a supported, audited recovery path for orphaned channel ownership

## Summary

Buzz Desktop can leave a community operator without a supported way to restore channel ownership after an identity transition. In the observed case, the active community owner remains only a channel member while an earlier identity remains the channel's sole owner, so the active operator cannot use the normal Desktop controls to manage channel roles or retire the channel.

This issue requests a maintainer-designed, narrowly scoped, and audited recovery path. It does not propose widening ordinary community-owner authority over healthy channels.

## Observed Desktop outcome

1. A community and one of its channels were originally created under Identity A.
2. Community operation later moved to Identity B, but the channel-specific owner role remained with A.
3. Identity B is an active member of the original channel and is the current human community owner.
4. Buzz Desktop exposes no supported action for B to establish a new channel owner.

The affected channel remains active and contains messages, threads, human and agent memberships, canvas state, and workflow bindings that must remain attached to its existing channel UUID.

Deleting and recreating the channel is not an acceptable recovery path: it would break continuity and does not preserve those existing relationships.

## Requested outcome

Please define and implement an explicit recovery action that can restore a human channel owner while preserving the original channel and its history.

The recovery design should:

- Preserve the channel UUID, messages, threads, memberships, agent roster and roles, canvas, and workflow bindings.
- Be promotion-only: establish an eligible existing active human channel member as an owner without automatically removing or demoting anyone.
- Be transactional, idempotent, tenant-scoped, and concurrency-safe.
- Produce an immutable, channel-visible audit record that identifies the actor, prior owner set, promoted member, reason code, request event, and timestamp.
- Require explicit Desktop confirmation that names the channel, current owner set, promoted member, and recovery reason.
- Keep ordinary channel role management unchanged.

## Eligibility needs maintainer security review

The eligibility predicate must be approved by maintainers before implementation. An archived-identity record alone is not sufficient evidence that a channel owner is unavailable.

If archive evidence is used as one part of a candidate predicate, only durable self-consent archive evidence should qualify; an archive action performed through an administrative consent path must not by itself authorize ownership recovery.

That candidate signal does **not** cover a lost or deleted key that was never self-archived, including the incident that prompted this report. That case needs a separately approved recovery or attestation design rather than an inferred availability claim.

The authorization design should receive maintainer security review before code is proposed.

## Acceptance criteria

- A dedicated, documented recovery action exists; existing add-member and role-management authorization is not widened.
- The signer, target, channel, and community are authenticated and validated under a maintainer-approved eligibility predicate.
- The target is an existing active human member of the same community and channel.
- Recovery promotes the target to `owner` without automatically removing, demoting, archiving, deleting, or recreating anything.
- The original channel UUID and all continuity-sensitive data remain usable after recovery.
- Simultaneous attempts cannot overwrite unrelated membership changes or leave the channel without an owner.
- Negative tests cover unauthorized principals, agent signers, non-member targets, bot targets, cross-community targets, and every archive or availability state that does not satisfy the approved predicate.
- Preservation tests cover messages and threads, human and agent memberships, canvas state, and workflows targeting the channel.

## Non-goals

- No general community-owner bypass of channel governance.
- No inference that an offline, inactive, archived, or inaccessible identity has lost its key.
- No automatic owner removal, demotion, archival, channel deletion, or channel recreation.
- No change to mention ranking or duplicate-name presentation; that UX issue is independent.

## Evidence scope

This report is based on one observed incident and a read-only source review at commit [`ab7aa8b1200710dbc2d7a8661ed5aab95c4199c1`](https://github.com/block/buzz/tree/ab7aa8b1200710dbc2d7a8661ed5aab95c4199c1). It establishes an unsupported Desktop recovery outcome, not the prevalence of the condition or a complete authorization design.

Start with the read-only source review at commit ab7aa8b1200710dbc2d7a8661ed5aab95c4199c1, tracing the existing Desktop channel role-management and ownership authorization entry points. Done requires a maintainer-approved eligibility and recovery design plus implementation and the listed negative, preservation, concurrency, audit, and continuity tests.

Written by the indexing model from the issue text.