feat: show thread replies in channel

[satunnaisotus-juho]

Summary

• add a community owner/admin-controlled setting, Show thread replies in channel, stored on the community profile and defaulting off
• expose that setting through NIP-11 and channel-window bounds so clients render the same community behavior
• when enabled, include all thread replies in the channel window and render them as flat chronological channel rows, not nested/indented under the root
• keep display projection as the source of truth: no duplicate channel events are published, so edits/deletes/reactions/read state stay tied to the original reply event id
• add Replying to <root author> context plus a View original thread backlink that jumps to the root and opens the side thread panel
• make Reply on a projected reply target the original thread/reply from the main composer without opening the side panel
• document the community row mode in NIP-CW, the bridge channel-window contract, NIP-RS read-state semantics, and NIP-WP workspace profile writes
• tighten the 9033 relay-admin permission matrix and pin that rosterless open relays can set icons, but not thread-display policy, without an admin/owner row

Motivation

Thread replies often go unnoticed and get buried when people read only the main channel. This gives communities that prefer Slack-style channel visibility an owner/admin-controlled way to surface thread replies chronologically in the channel timeline, while keeping the original thread reply as the single source of truth.

Review Status

• Current review head: bc3e8df3dbdb6477b29f64546ff8ff35d61f2292
• Merged origin/main at 779af8886caae1317b4de962082429867ab61503 into the PR branch.
• The feature migration was renumbered to migrations/0047_thread_replies_in_channel.sql to follow upstream migrations through 0046_storage_accounting_snapshots.sql.
• GitHub reports the branch as mergeable; DCO Check passes at the current head.
• Codex Security Review requires a Block organization MEMBER or OWNER to authorize the current head with @buzz-security-review bc3e8df3dbdb6477b29f64546ff8ff35d61f2292.
• Formal code-owner review is requested from @block/buzz-oss-team.

Successfully merging this pull request may close these issues.

Closes #5514.

Duplicate Search / Issue

• feat(desktop): "Also send to channel" option when replying in a thread #5514, feat(desktop): "Also send to channel" option when replying in a thread, describes the same channel-visibility problem and explicitly notes a single-event/rendered-in-both-places approach as preferred.
• This PR intentionally implements the maintainer-confirmed community-level display projection variant rather than a per-reply author checkbox/toggle.
• Open issue search for "thread replies" "channel" returned feat(desktop): "Also send to channel" option when replying in a thread #5514 plus unrelated mobile/ACP thread bugs.
• Open issue search for "inline thread" returned feat(desktop): pin open threads in a persistent switchable rail #4266, a persistent thread rail request rather than channel-row projection.
• Open PR search for "thread replies" "channel" found mobile/notification/thread-reply fixes and this PR, but no duplicate projection PR.
• Open PR search for "also send to channel" returned no results.
• No separate issue was opened after the PR because the scope was confirmed in the originating maintainer Buzz thread; feat(desktop): "Also send to channel" option when replying in a thread #5514 is the closest existing issue.

UI Evidence

Community setting:

Projected replies in the channel feed:

Manual Testing

1. Check out the PR branch locally:

   gh pr checkout 6695
   git status --short --branch
   git rev-parse HEAD

   Expected head at update time: bc3e8df3dbdb6477b29f64546ff8ff35d61f2292.

2. Start the desktop app from the PR worktree:

   . ./bin/activate-hermit
   just setup # first time only
   just dev

3. As a community owner/admin, open Settings -> Appearance and enable Show thread replies in channel.

4. Open a stream channel with thread replies and verify:

   • replies appear as peer-level main channel rows in chronological order by their own timestamp
   • projected rows show Replying to <root author> and View original thread
   • clicking View original thread jumps to the root message and opens the side thread panel
   • clicking Reply on a projected row targets that thread/reply in the main composer without opening the side panel
   • no duplicate channel event is created for the projected row

Tests

• Current head bc3e8df3dbdb6477b29f64546ff8ff35d61f2292: CARGO_INCREMENTAL=0 ./bin/just ci passed after merging origin/main; the same shell printed HEAD_AFTER_CI=bc3e8df3dbdb6477b29f64546ff8ff35d61f2292.
• Current head bc3e8df3dbdb6477b29f64546ff8ff35d61f2292: git diff --check origin/main...HEAD passed.
• Current PR head: GitHub DCO Check passes.
• Current PR head: GitHub Codex Security Review is awaiting manual authorization by a Block organization MEMBER or OWNER for the exact head SHA.
• Focused desktop pure tests for channel windows, timeline projection, unread markers, and virtualized timeline keys passed before the full gate.
• Focused Rust tests for relay admin profile updates, NIP-11 exposure, DB migration registration, and the channel-window projection query passed before the full gate.
• ./bin/cargo test -p buzz-relay 9033 -- --ignored passed, including the rosterless icon-allowed/thread-display-rejected handler regression.
• Desktop screenshot helper captured the two UI evidence images above with threadRepliesInChannel enabled.

[satunnaisotus-juho]

UI Evidence

Default panel mode: thread replies stay behind the root summary row.

Inline mode: clicking the summary expands visible replies in the main timeline, with Open in thread as the backlink to the full panel.

Note: the repo screenshot helper could not push to block/buzz from this fork checkout due upstream permissions, so these PNGs are hosted immutably from satunnaisotus-juho/buzz using the same git-object pattern.

[satunnaisotus-juho]

@block/buzz-oss-team ready for code-owner re-review after the final schema desired-state fix.

Current head: 8fce7979ed20aa476874f14f50ec044e3f5c9d24

The last follow-up commit only adds communities.thread_replies_in_channel to schema/schema.sql so fresh/isolated DB setup matches migration 0033_thread_replies_in_channel.sql. DCO is green; local focused DB check passed with bin/cargo test -p buzz-db.

[satunnaisotus-juho]

@block/buzz-oss-team latest main is merged into this PR now, and the conflict resolution is pushed.

Current head: bab646296b32a8477482af8568c5aee190ca20ae

Verification:

• ./bin/just ci passed locally at that exact head after merging origin/main.
• GitHub reports mergeable=MERGEABLE.
• The requested code-owner team remains buzz-oss-team; reviewDecision=REVIEW_REQUIRED.

One GitHub automation note: Codex Security Review / Mark Previous Review Stale failed because the workflow token got 403 Resource not accessible by integration while trying to post the stale-review notice. This fork PR has author association NONE, so the workflow requires a Block organization MEMBER or OWNER to authorize the current head by commenting exactly:

@buzz-security-review bab646296b32a8477482af8568c5aee190ca20ae

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is 779af8886caae1317b4de962082429867ab61503...bc3e8df3dbdb6477b29f64546ff8ff35d61f2292.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review bc3e8df3dbdb6477b29f64546ff8ff35d61f2292 to authorize a new review.
Any previous review applies only to its recorded range.

[satunnaisotus-juho]

@block/buzz-oss-team PR is green and mergeable again at f951e8a11e9626e988669162efe54345bff568c6. Could someone do the code-owner review and, if authorized, kick the security review with:

@buzz-security-review f951e8a11e9626e988669162efe54345bff568c6