Store appearance and behavior settings on the server that serves the web app

[hilman2]

TL;DR: Client settings live in localStorage, so they differ per browser and per origin. I'd like the server that serves the web app to store them, the way environment themes already work. Is that direction wanted, and which design do you prefer?

Questions

1. Separate file (e.g. webclientsettings.json) next to settings.json and keybindings.json, or new keys in ServerSettings? The second reuses the existing RPC, patch, stream and scope machinery. The first keeps machine config and UI preferences apart.
2. Which keys sync and which stay per device? My guess: fonts, contrast, chatWidth, timestampFormat, diffLayout, sidebar and composer behavior, favorites sync. Panel widths, zoom, browser viewport and desktop-only options stay local.
3. Should the desktop app move its local settings file to its main local environment, or keep it?

Problem

ClientSettingsSchema (packages/contracts/src/settings.ts) is persisted in localStorage["t3code:client-settings:v1"] on web and in a local file on desktop. Theme, sidebar order and composer drafts use their own t3code:* keys.

• A second browser, a phone browser, or the same server under another hostname starts with defaults.
• The first-run wizard shows again, because onboardingCompletedAt is per browser.
• Clearing site data resets everything.

Proposal

• The server that serves the web app owns a small settings document. Clients read and patch it over RPC and receive changes live.
• Same scope as environment themes: the serving server, or the desktop app's main local environment. app.t3.codes and additional connections keep using localStorage.
• The local copy stays as a startup cache, so the theme applies before the first paint and the app works while disconnected. On connect the server's values win and are applied. Edits are written to the server immediately.
• Until the first load, a client without a cache shows the neutral state, as the legacy sidebar and environment identification settings already do. No new animation.
• Syncing between several servers is a separate, later step.
• One-time import of existing localStorage values on first connect.
• Mobile does not read ClientSettings today and stays out of scope.

I can implement this if you approve the direction and scope.

[colonelpanic8]

Your first two questions (a separate file vs new ServerSettings keys, and which keys sync vs stay per device) are what #19593 asks maintainers to settle as a general rule for client vs environment ownership. #19592 covers giving web client settings a file form at all.