feat(profile): Message settings group — visibility, length, page size, advanced options (#32)

[Adron]

Closes #32. Part of epic #31. Builds on the #33 scaffold.

Grouping mirrors the web — verified, not guessed

The issue flagged that the web puts the character limit under Profile, not Message settings.
Confirmed against the live help centre: /help/settings lists Profile settings → "Max message
length: Character limit per message (default 666)"; View preferences → "Messages per page: How
many messages to load at once (10 to 30)"; Message settings → "Default message visibility" +
"Advanced post settings". /help/messages is blunter still: "Each user has a configurable message
length limit (default 666 characters). Adjust it in Settings, then Profile (not Message
Settings)."

So:

Group	Setting
Profile (new)	Message character limit
View preferences (existing, appended)	Messages per page
Message settings (new)	Default message visibility, Advanced post settings

Discoverable either way — the Message settings group description says "As on the web, the character
limit is under Profile and the page size under View preferences."

The numeric row

SettingsNumberRow: digits-only field flanked by −/+ steppers. It reports a value only when the
entry is a whole number inside its range (on IME Done or a stepper tap), so nonsense can never reach
the API; an invalid entry shows an inline bounds message and is discarded on blur. The field is
keyed on the incoming value, so an optimistic value the server later rejects is replaced by the
restored one rather than lingering on screen. The ViewModel re-checks the range as the real backstop
and refuses out-of-range values without a request.

Bounds live in SettingsBounds: MESSAGES_PER_PAGE = 10..30 (documented),
MAX_MESSAGE_LENGTH = 10..10_000 — deliberately wide, because no cap is documented anywhere and a
legitimate value must never be blocked client-side.

Request-side types — the question from #33 is now answered

The generated spec types maxMessageLength, messagesPerPage, defaultPubliclyVisible,
showPreviews, showAdvancedPostSettings, latitude, longitude and notificationTrayLimit as
string, yet types isPrivateAccount as boolean. That inconsistency only makes sense if the
generator inferred from a coercing handler rather than a real contract — and the spec's own 200
example returns maxMessageLength: 666 as a number. The live GET /api/user agrees.

So the spec's string is a generator artifact; the repo's natural-JSON-types choice stands, and the
tests now assert isString == false on the wire body for all four fields.

Verification

./gradlew :app:assembleDebug testDebugUnitTest → BUILD SUCCESSFUL, 821 tests repo-wide, 0
failures. Coverage: each of the four fields PATCHes alone (asserted at repository level on the
actual JSON key set and primitive type, and at ViewModel level through the real mapper);
optimistic apply + rollback for both switch and numeric rows; out-of-bounds refused with zero
requests; a server rejection restoring the previous value with the server's own wording surfaced.
10 Compose tests compile but were not executed (no emulator).

Reviewer notes

• Deliberately not done: the composer and feed do not consume these values. The issue text
  mentions it, but that is the :feature:messages lane — Composer: honour the account's character limit and the tightest cross-post limit #24 (character limit) and Feed: view preferences (All / My / Following / Followers) and onlyMine #19 (feed
  preferences); Composer: public/private visibility toggle (publiclyVisible) #18 already consumes defaultPubliclyVisible. No file outside :feature:profile
  was touched.
• SettingsScreen now takes 9 callbacks and will reach ~13 as Settings: private account toggle (isPrivateAccount) #34–Settings: profile location (latitude/longitude) with runtime permission #37 land. Worth folding into a
  single SettingsActions holder once those merge — doing it now would conflict with every sibling
  branch.
• MAX_MESSAGE_LENGTH = 10..10_000 is a judgement call, not a contract. If the server's real cap
  surfaces, tighten it so users get inline validation instead of a round-trip rejection.
• Settings: theme preference synced to the account (theme) #36 (theme) will likely want the same Profile group — expect a small merge conflict there.