[wpfleger96]

Reading, mark read, whole-channel mark unread and thread follow choices now sync across a person's installations. This PR specifies the rules in NIP-RS and implements them in the mobile app.

Spec (docs/nips/NIP-RS.md)

• Defines catch-up and displayed.
• A catch-up advances the channel's own frontier (top-level messages) or thread:<root>. activity: and thread-activity: become read-only legacy keys.
• Explicit mark read is synchronized state. A first explicit read of a message with no override group writes only its msg: frontier. Display, dwell, scroll, catch-up and mention visibility create no msg: entries.
• Only whole-channel override groups are published, merged and cleared with the counter. Readers ignore peer msg: and thread: groups.
• Single-message and thread mark unread stay on the device. They end once the merged frontier covering them passes their baseline, from any installation, or on display, catch-up or explicit read. The section also states clearing scope, the accepted concurrency limitation and capacity.
• When the merged override union no longer fits the primary, the client rewrites the primary compactly from the groups its last published primary carried, each canonical against current frontiers. It never omits merged groups or tombstone floors that primary carried, and override actions fail visibly.
• Adds Buzz Thread Follow Choices: thread-follows:<32hex> coordinates, validation, three-state verdict, last-writer merge with ties going to unfollow, publication and recovery, legacy import at at = 0, and capacity.

Mobile

• Catch-up writes the main frontier. A flat timeline reads up to the newest top-level message it reached.
• Explicit mark read publishes. Passive msg: marks stay on the device.
• Whole-channel mark unread publishes an override group and merges peer groups. An explicit read or catch-up clears it, even when no frontier moves. The action fails visibly at the uint32 limit or when the primary is full. A synced clear the primary can't carry is rolled back, and the channel view reports it once while the failure stands.
• Device-local message and Inbox unread overrides record a baseline and clear when a covering frontier passes it, including one merged from a peer.
• Thread follows move from local storage to the synced thread-follows: slots. They share the read-state client_id, journal, created_at sequence, snapshot and live subscription, and spill across up to 16 slots with stable placement. An unreadable coordinate marks follow state incomplete and blocks this installation's follow publication.
• Follow and unfollow are refused on every cold start of the writer until its first complete recovery of its own state succeeds and every owned follow head is readable. Cached follows show at once. A refused tap changes nothing and shows "Follow choices are not ready. Connect and try again." Reads, catch-up and both kinds of mark unread are not gated.
• A follow tap is accepted only once journaled. The accepted own head, pending edits and the exact in-flight packet are kept apart, so a retry or restore never drops or re-attributes an edit.
• Pre-sync local follows are imported at at = 0 after a complete merge, once their channel is known from a relay event. An imported key is settled, and its legacy copy retired, only when the journal write the import awaited covered it and that entry is still current.
• An explicit unfollow suppresses ordinary replies at live and catch-up admission. A change in follow choices drops the unread replies already counted for an unfollowed thread, and rechecks the channels of a newly followed one.
• Two-device fixtures against an in-memory relay cover channel round-trips and clears, stray message groups, the first explicit message read, the primary cap, follow propagation, same-second and backward-clock follow publication, legacy import, retry after a failed publish, unreadable coordinates and slot packing. Recovery fixtures cover the startup gate, journal failures during flush, interleaved legacy imports, and restore of an older journal.

Related: block/buzz-app#3552

[wpfleger96]

Desktop counterpart (new Buzz): block/buzz-app#3552