fix(desktop): require explicit action to mark Inbox read

[MajorTal]

Hey good people, I'm Tal and this is my first contribution to this (awesome) project. It's a bug that was bothering me while dogfooding Buzz. I hope it's in good order...

Summary

Previewing an unread Inbox item currently calls the same read-state mutation as the explicit Mark as read action. That makes ordinary browsing consume the unread queue, and in unread-only mode it can remove the row merely because it was opened.

This change separates selection from completion:

• Opening or keyboard-previewing an Inbox item leaves it unread.
• Mark as read remains the explicit completion action and publishes the existing persisted NIP-RS read state.
• In unread-only mode, completing the selected item removes it and predictably selects the next item on wide layouts; narrow layouts return to the list.
• Mark unread continues to restore the item coherently.

The implementation keeps the existing persistence path intact and adds a small pure selection helper so next-row behavior is independently testable.

User impact: people can inspect and move through their unread Inbox without losing the queue, while explicit completion still synchronizes through the existing read-state mechanism.

Related issue

Fixes #3683.

No duplicate open PRs were found for this issue.

Testing

• . ./bin/activate-hermit && just ci on the rebased commit
• 3 focused unit tests for explicit-completion selection
• Chromium Playwright regression covering keyboard preview, unread-only retention, explicit completion, persisted read-state publication, next-row selection, and manual mark-unread
• Existing Inbox-focused Playwright coverage
• Manual local UI verification of selection, unread styling, unread-only filtering, and the explicit context-menu action

Manual verification:

1. Enable Show unread only in Inbox.
2. Open several unread items with the mouse or Enter and verify they remain visible and unread.
3. Use Mark as read on the selected item and verify it leaves the unread queue.
4. Verify the next unread item is selected on a wide layout.
5. Disable unread-only, use Mark unread, and confirm the item returns to the unread queue.

There is no layout or styling change, so static before/after screenshots would show the same UI. The interaction and read-state transition are covered by the Chromium regression and manual steps above.

Release note: Inbox items no longer become read when you open them, by click or by keyboard. Clear an item with the explicit "Mark as read" button.

[Chessing234]

good first contribution. the explicit mark-as-read split matches how people skim an inbox. one ask: does keyboard/shortcut open of an unread item still auto-mark, or only click-to-preview?

[Chessing234]

explicit mark-read is the right default for an inbox that also drives detail selection. the wide-vs-narrow completion selection tests look solid. one product ask: if users relied on auto-read-on-open, a one-line settings toggle (or release note) will save the "my badge never clears" reports after this lands.

[MajorTal]

Thanks! Keyboard opening is covered too. The test focuses an unread row, presses Enter, and checks that it stays unread until Mark as read is used.

Good point about letting people know about the change. Since #3683 specifically asks for explicit-only read behavior, I left a settings toggle out for now. Happy to add a changelog note if the maintainers want one.

[Chessing234]

explicit mark-read for inbox is the right default for a noisy feed — auto-read was too easy to miss.

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

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

[MajorTal]

Good question, and sorry for the silence. August happened.

Keyboard open behaves exactly like click-to-preview: Enter selects the row and shows the preview, nothing gets marked. The only thing that clears an item is the explicit "Mark as read" button. Same rule for mouse and keyboard, on purpose. The e2e spec (inbox-explicit-read.spec.ts) drives the whole flow with Enter for exactly this reason.

On the settings toggle: I'd rather not. Two behaviors for one badge is how you get the "my badge never clears" reports from the other half of the users. A release-note line does the job; I added one to the PR description.

Branch is updated on today's main.

[MajorTal]

Closing this since the desktop frontend is moving to block/buzz-app. Changing Inbox behaviour in the outgoing client isn't a good use of review time.

For whoever ports Inbox over: the bug in #3683 is still live on main. Selecting an item marks it read right away (HomeView.tsx, onSelect calls handleUserSelectItem(itemId) then markItemRead(itemId)). The behaviour this PR aimed for is simple to carry across: selecting or pressing Enter only previews, and the explicit "Mark as read" action is the only thing that clears an item, for mouse and keyboard alike. inbox-explicit-read.spec.ts in this branch drives that flow end to end and would make a good acceptance test in the new app.

Thanks @Chessing234 for the review.