Settings: edit every server-side preference, and honor theme for real (#46)

[Adron]

Closes #46

Recreates #167. That PR was auto-closed by GitHub when its base branch issue-127-wire-types was deleted on merge of #131 — my mistake for merging with --delete-branch while dependents still pointed at it. Same branch, same commits, now based on main (which contains the CurrentUser fields it needed). The original discussion, including my review, is on #167.

What this does

#131 modelled the 14 missing preference fields; this makes them editable and effective. All 15 PATCH /api/user/update field names verified live and round-tripping: displayName, bio, avatar, isPrivateAccount, githubDefaultRepo, theme, maxMessageLength, messagesPerPage, viewingPreference, showPreviews, notificationTrayLimit, defaultPubliclyVisible, showAdvancedPostSettings, latitude, longitude.

It also fixes a live bug — see #171

"Save profile" has never worked. UpdateProfileAsync built its body from an anonymous object, and JsonSerializerDefaults.Web doesn't drop nulls, so every save shipped "theme": null:

A) what Save profile sent:  {"displayName":"…","bio":"…","isPrivateAccount":false,"theme":null}
   -> HTTP 500 {"error":"Internal server error"}
B) same body, null removed
   -> HTTP 200 {"message":"User updated successfully"}

Both writers now build a sparse dictionary. The generalisation is on #171: any PATCH body built from an anonymous object with optional parameters is a latent 500 on this API.

Four findings that shaped the implementation

1. Native JSON numbers/booleans are correct — the OpenAPI request schema is wrong, typing every field as "string". (The response schema uses native types.)
2. viewingPreference is enum-validated, and the server named its own values in a 400: my_messages, all_messages, followers_only, following_only.
3. theme is not validated — it accepted and stored "zzz_bogus". So ResolveDark treats anything unrecognized as "follow the OS", and the OS listener is retained.
4. The PATCH 200's user is narrower than GET /api/user (no accountStatus/cleared/pendingEmail/isAdministrator), so deserializing it would blank Settings: account-status banner and gated-feature messaging #50's banner fields — callers re-fetch.

Live ranges from 400s, now validated client-side: maxMessageLength 1–10000, messagesPerPage 10–30, notificationTrayLimit 10–40.

Consumers still needing wiring

Six consumption points sit in files held by other PRs, each spelled out with its exact one-line change: messagesPerPage, notificationTrayLimit, maxMessageLength, showAdvancedPostSettings, showPreviews, viewingPreference. defaultPubliclyVisible was already honored; theme is done here.

Two of those are not one-liners: viewingPreference needs a product decision (followers_only/following_only have no server-side equivalent — see #36), and showPreviews has nothing to gate yet since nothing calls the metadata endpoint.

Shared-account hygiene

Nine fields were probed off their real values and all nine restored, confirmed by a GET /api/user that diffed byte-identical to the pre-probe capture. No identifying field touched.

Builds green in Debug and Release.

🤖 Generated with Claude Code