feat(desktop): "Also send to channel" option when replying in a thread

## Summary

When composing a reply inside a thread, add a control (checkbox/toggle or a secondary send button) that **also posts the reply to the main channel timeline** — not just into the thread. Slack calls this "Also send to #channel."

## Motivation

Threads keep focused sub-conversations tidy, but important replies (decisions, "PR is up", blockers, results) often need to be visible to everyone in the channel, not only people who happen to have that thread open. Today the author has to choose: reply in-thread (loses channel visibility) or reply top-level (loses thread context). This forces awkward workarounds like copy-pasting the reply as a second top-level message, which duplicates content and breaks the thread linkage.

A one-click "also send to channel" preserves the thread structure **and** surfaces the message on the main timeline in a single action.

## Proposed behavior

- In the thread reply composer, add a toggle/checkbox labeled something like **"Also send to channel"** (mirrors Slack's affordance).
- When enabled, the message is threaded as normal (keeps its NIP-10 reply/root tags) **and** is surfaced on the parent channel timeline.
- Default off; remembering the last choice per user is a nice-to-have, not required.
- The channel-timeline rendering should indicate it originated from a thread (e.g. "replied to a thread") and link back to the thread, so it doesn't read as a context-free top-level post.

## Notes / open questions

- Implementation could be a single event that the client renders in both places (preferred — no duplicate content, no double notifications), vs. emitting a second top-level event. The single-event approach avoids the duplicate-content problem and keeps edit/delete coherent.
- Applies to Desktop primarily; mobile parity would be ideal.

## Duplicate check

Searched open + closed issues (`also send`, `broadcast`, `crosspost`, `reply to channel`, `also to channel`, thread/reply terms). Nearest neighbors are unrelated: #4585 (thread sort order), #3160 (notification broadcast opt-out), #4266 (pin threads rail), #4072 (agents reply to triggering message). No existing request for surfacing a thread reply to the main channel.

---
_Requested by a Buzz user via chat; filed by their AI agent (DefinitelyNotFizz)._

Start by tracing the desktop thread reply composer and the channel-timeline rendering described in the issue, then inspect how NIP-10 reply/root tags and message notifications are handled. Done means a reply can remain in its thread while also appearing on the main channel timeline, with a clear thread link or origin indicator and coherent edit/delete behavior.

Written by the indexing model from the issue text.