fix(settings): self-describing item count in SettingsScreen

[PonceGL]

What

totalItems = mainCategories.size + 3 counts three trailing items (Device
Capabilities, Accounts, About) rendered by hand right after the category
loop, with a comment naming them — two sources of truth for the same fact.
Whoever adds a fourth trailing item and forgets the literal breaks the last
item's rounded corner. One of the small independent fixes listed in #2813.

The original justification for this fix (as scoped) turned out to be
wrong, verified against the code: adding a SettingsCategory does not
trigger the bug — mainCategories.size is already dynamic. The real
fragility is the literal + 3 itself, disconnected from the three
ExpressiveXxxItem calls it's supposed to count.

Change

A private TrailingSettingsItem enum (DEVICE_CAPABILITIES, ACCOUNTS,
ABOUT) rendered via forEach + an exhaustive when, the same pattern
already used for mainCategories. totalItems = mainCategories.size + trailingItems.size — a real collection's size, not a literal. Adding a
fourth item now needs a new enum entry, and the compiler refuses to build
until the when covers it — the bug class becomes impossible, not just
less likely.

A self-review pass (before this PR went up) found the first version of this
fix only half-solved the duplication: the loop's own exclusion filter
(it != ABOUT && it != DEVICE_CAPABILITIES) was a second, independent
list of the same two categories. Fixed by giving TrailingSettingsItem a
nullable category: SettingsCategory? (null for Accounts, which isn't a
category) and deriving the loop's filter from it — one enum now drives both
the count and the exclusion.

Zero behavior change: same onClick, same colors, same order, same
shapeFor()/itemIndex bookkeeping.

Testing

No automated test added — SettingsScreen needs the full Hilt graph
(NavController, PlayerViewModel with ~30 dependencies, SettingsViewModel
via hiltViewModel()) to instantiate at all, and there's no existing Compose
test for this screen to build on; standing that up just for a
compiler-enforced, non-behavior-changing refactor felt disproportionate.

Attempted on-device visual verification instead; blocked by a sandbox
limitation in my own environment (synthetic input events never reached the
emulator — confirmed via raw getevent capture, unrelated to the app).
Verified instead: assembleDebug succeeds, full JVM baseline unaffected (5
pre-existing failures, none new), and the diff traced by hand against the
original for behavioral equivalence.

[PonceGL]

Closing for now — reorganizing how this work is staged. It'll go through our fork first and we'll propose it upstream again, possibly bundled differently, once the larger feature it's part of is further along. Not a rejection, just a process change on our side.