feat(clients): an OLED palette, and split WHETHER the gamepad UI is offered from WHEN it appears

Four changes to the client interface, kept together because two of them touch the same rows
and the last is a bug the first would have made far more visible.

A thirteenth `ui_palette` entry, `oled`. The palette table is hand-mirrored in three languages
(`pf-console-ui`'s `library.rs`, `GamepadPalette.swift`, `GamepadPalette.kt`), so it goes into
all three at index 1, directly after the brand default — which keeps `PALETTES[0]` the unknown-id
fallback and keeps the dark-to-pale cycling order intact. What earns the name is arithmetic, not
a darker shade of violet: the ramp's first two stops are literally (0,0,0) and the ground is pure
black, so the shaded half of the field is pixels switched off rather than "very dark grey", and
the calm mix the form screens sit under lifts toward nothing at all. Mean cell luminance is 0.019
against Violet's 0.254. The bright corner keeps a faint indigo-to-violet ember so the backdrop is
still a field with somewhere to go, and that ember carries enough chroma at that luminance
(60 degrees of hue travel across 13 of the 16 cells) to satisfy the existing multi-tone assertion
without adding `oled` to the near-neutral exemption Graphite and Opal take. Each port gains an
`oled_is_actually_black` test that measures the claim — pure-black corner cells, a mean under half
the darkest other field's — rather than restating the table.

A new device key, `gamepad_ui_mode`. The gamepad-UI switch had been deciding two things at once:
whether to offer the controller-optimized interface at all, and that it appears only while a pad
is attached. A user asked for the second half to stop applying. `"connected"` (the default, and
exactly what the lone Bool meant) and `"always"` separate them, surfaced as a "Show it" row
directly under the switch on all five settings surfaces and built only while that switch is on —
a picker whose every option decides nothing is worse than no picker. `GamepadUIEnvironment.isActive`
takes the mode with NO default argument on purpose: a call site that forgot it would silently
strand everyone who chose Always back on "only with a controller", which is the one bug this
parameter exists to make impossible. An unrecognized value waits for a controller, so a mode a
newer client wrote can never trap an older one in a layout it has no way back out of. It stays a
device preference on both platforms, never part of a profile: which interface this device wears
has nothing to do with how a host streams to it.

The smoothness buffer is hidden under Lowest latency, not dimmed. Everywhere else already hid it
— the GTK and WinUI shells, the Apple touch and tvOS screens, the Android touch screen — because
under that intent it names a quantity that does not exist. Two surfaces disagreed: Apple's gamepad
settings screen left the row live and steppable, and the desktop console dimmed it, having no way
to drop a row from a fixed list. That list is now rebuilt each frame through a `row_applies`
filter. The concern about a vanishing row moving everything under the cursor does not apply here
and the new test says why: the row it drops sits directly BELOW the row that drops it, so the only
cursor that can be present when the list shrinks is the one on the intent row, which does not
move. Two latent hazards went with it — `apply_row` had been indexing the row list on the
assumption the cursor is always in range, and nothing re-clamped that cursor when another writer
changed the intent behind the screen's back.

Pale palettes were unreadable on tvOS, reported from the field. `GamepadInk` was never the
problem: it flips correctly for a pale field, it is not platform-gated, and every tvOS gamepad
entry point already published it. The cause is that this app sets `preferredColorScheme` nowhere
and declares no `UIUserInterfaceStyle`, so every SYSTEM-derived colour landing on those screens —
a `.secondary` placeholder, a `.bordered` button's chrome, a NavigationStack title, a material's
frost — resolved against the DEVICE appearance, which the palette cannot reach. On iPhone, iPad
and Mac a great many users sit in Light mode, so under a pale palette those colours came out dark
and the theme looked correct by accident; an Apple TV is Dark essentially always, so every one of
them rendered white on a light field. The mirror image was broken too and had simply never been
reported: a dark palette on a Light-mode iPhone was already drawing dark on dark. The scheme is
now published beside the ink, once, in `GamepadInkModifier`, because the two are halves of one
decision and publishing only the ink silently loses every colour the frameworks draw on the app's
behalf. Two structural amplifiers went with it: `ConsoleGlass` had been scoping the scheme to the
fill inside its `.background {}` on the tvOS and pre-26 branches while the 26 branch put it on the
content, so no console row's own content ever saw it on tvOS; and `LibraryView`'s navigation
chrome and its loading, error and empty states sit above `LibraryCoverflowView` and so were never
inked at all on tvOS and macOS, where that view is presented directly rather than through the
iOS-only `GamepadLibraryScreen` wrapper.

That last one exposed a second tvOS gap worth closing in the same breath: `ui_palette` had no row
in tvOS's ordinary Settings, and the gamepad settings screen that owns it everywhere else needs an
extended-profile controller to open on tvOS. An Apple TV driven by the Siri Remote alone could not
reach the palettes at all, which would now include the OLED one. `SettingsView.tvBody` carries a
Background row.

Verified: pf-console-ui builds, passes `clippy --all-targets -D warnings` and runs 74 tests clean
under linux/amd64 (a Mac `cargo check` of that crate is vacuous — every module is cfg'd to
linux/windows); `cargo fmt --check` clean for it and pf-client-core. Android `:app` runs 80 tests
with 0 failures, including four new `gamepadUiActive` cases and the palette parity table. The
Apple package builds for macOS AND tvOS and its 9 palette/gamepad-UI tests pass — the tvOS
typecheck is possible because the checked-in xcframework already carries a `tvos-arm64` slice. The
tvOS RENDERING fix is compile-verified only; an on-glass Apple TV check under a pale palette is
still owed, and is the one thing here that a build cannot answer.

docs-site/content/docs/client-settings.md

@@ -96,11 +96,12 @@ those hiccups out, at that buffer's worth of added delay. Linux and Windows apps
 home; the Apple and Android apps have carried the same setting for a while, and it is stored
 under the same name, so a [profile](/docs/profiles-and-links) means the same thing on every device.
 
-**Smoothness buffer** — *default: Automatic (two frames).* Only shown under **Smoothness**. How
-many frames are held back before showing. Each frame absorbs roughly one screen refresh of network
-hiccup and costs one refresh of delay — so on a 120 Hz screen, two frames is about 17 ms of extra
-delay bought against 17 ms of jitter. If you never see stutter, you don't need this. Wherever
-**Prioritize** is offered, and greyed out until you pick Smoothness.
+**Smoothness buffer** — *default: Automatic (two frames).* How many frames are held back before
+showing. Each frame absorbs roughly one screen refresh of network hiccup and costs one refresh of
+delay — so on a 120 Hz screen, two frames is about 17 ms of extra delay bought against 17 ms of
+jitter. If you never see stutter, you don't need this. The row appears wherever **Prioritize** is
+offered, and only once you have picked **Smoothness** — under Lowest latency there are no held
+frames for it to count, so it isn't shown at all.
 
 **V-Sync** — *default: on.* Tear-free presentation. Turning it off asks the GPU to show each frame
 the instant it's ready instead of waiting for the screen's next refresh: the lowest delay a display
@@ -263,6 +264,43 @@ when you return to the host list. The console home carries the row for the deskt
 shares the store — a Gaming-Mode launch is fullscreen whatever it says. iPhone, iPad, Apple TV
 and Android have no equivalent.
 
+## Interface
+
+These change how the client itself looks and behaves. None of them touches a stream, so none of them
+can live in a [profile](/docs/profiles-and-links) — they are decisions about the device in front of
+you.
+
+**Gamepad-optimized browsing** — *default: on.* Swaps the touch or desktop home for the
+controller-optimized one: the host carousel, larger focus targets, a swipeable cover browser, and
+settings you can step with a thumbstick. The Apple and Android apps have this switch. Turn it off to
+stay in the touch interface even with a pad in your hands. On Linux, Windows and the Steam Deck the
+controller-optimized home is a separate entry point rather than a switch, so there is nothing to
+turn off. An Android TV is always in this mode — its remote is the only input it has.
+
+**Show it** — *default: With a controller.* Only shown while the switch above is on, and it decides
+*when* that switch takes effect. **With a controller** is the long-standing behaviour: the
+controller-optimized home appears as a pad connects and the touch interface returns when the last one
+disconnects. **Always** keeps the controller-optimized home either way — for a phone or tablet that
+lives docked to a TV, where the pad isn't always awake but the couch layout is always the one you
+want. Apple and Android. (An Android TV is in that mode regardless, so the choice changes nothing
+there.)
+
+**Background** — *default: Violet.* The colour family the controller-optimized home's living backdrop
+drifts through. Thirteen of them: seven dark fields — **Violet**, **OLED**, **Nebula**, **Abyss**,
+**Ember**, **Moss**, **Graphite** — then six pale ones, **Holo**, **Sunset**, **Bloom**, **Dawn**,
+**Mint** and **Opal**, which flip the whole interface to dark text on a light field. The backdrop
+recolours as you step the row, so pick by looking. **OLED** is the one with a practical point rather
+than a decorative one: it is true black — most of the frame is pixels switched off, which on an OLED
+or AMOLED panel means no glow and no power drawn, with only a faint violet ember left in one corner.
+Stored under the same name on every client, so a phone, a Deck and a desktop set to Mint all look
+alike. Appearance only — nothing about a stream depends on it.
+
+The row lives in the controller-optimized settings themselves — the screen you reach with **X** from
+the controller-optimized home — on every platform that has one, which includes the Steam Deck and the
+Linux and Windows console home. The Apple TV is the exception: it carries **Background** in its
+ordinary Settings instead, next to **Show it**, because its controller-optimized home needs a real
+controller to open and the palettes would otherwise be unreachable from the Siri Remote.
+
 ## Overlay
 
 **Statistics overlay** — *default: Normal.* Four tiers — Off, Compact, Normal, Detailed — each a
@@ -292,6 +330,10 @@ stay global and **cannot be put in a settings profile**:
   profile forwards.
 - **Auto-wake on connect** and **Show game library** — decisions about this device and this network,
   not about how a given host is streamed.
+- Everything under **Interface** — **Gamepad-optimized browsing**, **Show it** and **Background**.
+  How this client looks and which layout it wears has nothing to do with how a host streams to it,
+  so binding them to a host would only make the same device change appearance depending on what it
+  connected to.
 
 One switch you might expect here isn't in Settings at all: **Share clipboard** lives in a saved
 host's own edit sheet, because handing a machine your clipboard is a decision about that one host —