Settings & preferences parity — most of `PATCH /api/user/update` is unreachable from Android

[Adron]

The gap

UpdateProfileRequest in :feature:profile sends displayName and bio. PATCH /api/user/update accepts:

displayName, bio, avatar, theme, maxMessageLength, defaultPubliclyVisible,
messagesPerPage, viewingPreference, showPreviews, showAdvancedPostSettings, latitude,
longitude, isPrivateAccount, githubDefaultRepo, notificationTrayLimit.

Eleven of those fifteen have no Android surface at all. Several of them change behaviour the user
will notice immediately — default post visibility, feed contents, whether the account is private.

The web groups these under Settings (/help/settings): Profile settings, View preferences,
Message settings, Notifications, Profile location, Subscription & Billing, Security, Integrations,
AI features.

Done when

Android has a Settings surface that mirrors the web's groups, and every preference above is
readable and writable — with the feed, composer and notification surfaces actually respecting
them.

---

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]

All six sub-issues are done, so closing this epic.

• Settings: View preferences (viewingPreference) and link previews (showPreviews) #33 — Settings surface + view preferences and link previews → feat(profile): Settings surface + view preferences and link previews (#33) #93
• Settings: Message settings group (default visibility, max length, messages per page, advanced post settings) #32 — Message settings group → feat(profile): Message settings group — visibility, length, page size, advanced options (#32) #99
• Settings: private account toggle (isPrivateAccount) #34 — private account toggle → feat(profile): private account toggle under a Permissions group (#34) #105
• Settings: notification tray limit (notificationTrayLimit) #35 — notification tray limit (and both consumers honour it) → feat: notification tray limit — setting plus both consumers (#35) #112
• Settings: theme preference synced to the account (theme) #36 — theme synced to the account → feat(profile): sync the theme preference to the account, two-way (#36) #118
• Settings: profile location (latitude/longitude) with runtime permission #37 — profile location → feat(profile): profile location — coarse capture, manual entry, and an honest non-clear (#37) #130

All fifteen PATCH /api/user/update fields are now modelled, and every one that has a meaningful Android surface has one.

Four things this epic established that are worth keeping:

viewingPreference accepts only my_messages, all_messages, followers_only, following_only — confirmed from the server's own 400. The first implementation guessed all/mine/following/followers, which would have been rejected on every write.

theme is not validated at all — "not-a-theme", "sepia", "SYSTEM" and "" were each accepted and stored verbatim with a 200. Any client can put an account into a theme no client can render, so Android is deliberately the conservative side.

latitude/longitude cannot be unset — null, empty string and "null" all 400, and omission means "leave unchanged". That is an API gap; see #130.

The spec's request-side types are a generator artifact. It types maxMessageLength, messagesPerPage, showPreviews etc. as string while typing isPrivateAccount as boolean, and the live response returns all of them as their natural JSON types. The app sends natural types, now asserted in tests.

One item was not implementable: the web's Permissions section has an Email visibility setting with no corresponding field on GET /api/user or PATCH /api/user/update. Worth confirming whether that is an API gap or a web-only concept.

Follow-up still open: #104 (consolidate the now-three readers/writers of account preferences behind one owner).