Feed: view preferences (All / My / Following / Followers) and `onlyMine`

[Adron]

Part of #17 — Message composer & feed parity gaps

Web behaviour (/help/messages → Viewing preferences): Settings → View Preferences
chooses what the Home feed shows —

• All Messages — the user's messages plus all public messages
• My Messages — only the user's own
• Following Only — people the user follows, plus their own
• Followers Only — people who follow the user, plus their own

Android has no feed filter at all; getMessages sends only limit/offset.

• Read the account's viewingPreference and apply it to the feed query, using onlyMine where
  that is the server-side mechanism (confirm the exact query contract live for the
  following/followers variants before building).
• Offer an in-feed switcher as well as the Settings control, and persist the choice.

Tests: each preference produces the expected query; switching refreshes the feed.

---

Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.

[Adron]

Implemented in #103 (branch issue/19-feed-view-preferences). Closing here — review and any follow-up happens on the PR.

The open question in this issue — "confirm the exact query contract live for the following/followers variants" — is answered: there is no such query parameter. GET /api/messages takes only limit, offset, onlyMine and tag. /help/api/messages states that a signed-in token personalises the feed and that search is "scoped to your feed visibility (honors your viewingPreference)", so the server applies the stored preference itself. The implementation therefore PATCHes the preference and reloads, with onlyMine=true as the per-request mechanism for My Messages only.

One thing to consolidate later: :feature:profile's SettingsRepository (#33) and the new :core:network ViewingPreferenceStore are now two independent writers of the same field. Changing the view in Settings will not update an already-composed feed switcher until the feed is re-entered. Avoiding a feature→feature dependency was the right call, but these want one owner — most likely a shared account-preferences module — once both surfaces settle.