Theme: adopt the Strata dark palette across the app (dark mode is currently generic iOS)

[Adron]

Split out of #80, which covers the mechanical theme gaps (pre-auth/offline persistence, the logo's
cream backing square, system-blue links). This is gap 4 from that issue — the large, design-dependent
half — separated so the other three could ship without waiting on a design call.

The state of things

Dark mode works. It is just not InterlinedList's dark mode.

Services/ILColor.swift ships a complete dual palette built on dynamic UIColor:

background  light 0xF4EEE2  dark 0x121317
surface     light 0xFBF7EF  dark 0x17191F
surface2    light 0xF6F1E7  dark 0x1B1D23
text        light 0x16323C  dark 0xF3F1EA
textBody    light 0x22383E  dark 0xE4E1D9
masthead    light 0x184860  dark 0x0C2C3A
primary     light 0x2FA877  dark 0x3FBF8C
link        light 0x184860  dark 0x7FB8C4

But ILColor.background / .surface / .surface2 appear in roughly a dozen places across 54 view
files, and only MainTabView.swift:31 sets a screen background. Everything else uses system
materials, so in dark the app renders as Apple black/grey and the 0x121317 / 0x17191F Strata
palette is effectively unused. Confirmed on device: the masthead teal adapts correctly, the content
below it does not.

Why this needs a decision before code

This is not a bug with one right answer. It is a choice about how branded the app should look:

1. Fully branded — every screen background/surface uses ILColor, matching the web in both
   appearances. Most distinctive; most work; fights iOS conventions in places (grouped-list
   backgrounds, sheet materials, .searchable chrome) and risks looking non-native.
2. Branded chrome, native content — keep the teal masthead, ILColor.primary for actions and
   ILColor.link for links, but let lists and sheets use system materials. Cheapest, most native,
   least distinctive in dark.
3. Selective — brand the high-traffic surfaces (feed rows, list rows, document reader, compose)
   and leave incidental sheets native.

Question for whoever owns the design: which of these, and is there a reference for how the web's
dark mode is meant to feel on a phone?

If the answer is 1 or 3

• Decide the surface mapping once (screen background, card/row surface, grouped-list background,
  sheet background) and write it down, so 54 files do not each make their own choice.
• .scrollContentBackground(.hidden) plus an ILColor background is the usual SwiftUI route for
  List/Form; confirm that on one screen before doing it 30 times.
• Check contrast in both appearances — textBody on surface2 in dark especially.
• Watch the places already hardcoding .white on top of teal or image overlays
  (MainTabView.swift:96,129, FeedView.swift:349,359,372, ComposeImageStrip.swift:72-87).
  Those are correct as-is — white on a teal masthead or a dark scrim is right in both
  appearances — so they should NOT be swept into the token change.

Acceptance criteria

• A stated, written surface mapping that new screens can follow.
• Screenshot pass over feed, lists, documents, compose, profile and settings in both
  appearances.
• No contrast regressions; no screen left half-branded.

Not blocked by anything

#80's changes are independent — this can start whenever the design question is answered.

Files: Services/ILColor.swift (likely unchanged), adoption across InterlinedList/Views/.