Adopt new server-side app config for WebUI settings (personal settings storage + config.toml settings UI)

## Background

The backend has added server-side configuration support for WebUI app config. This makes it possible to move settings currently split between browser localStorage and the static `config.toml` file onto a centrally-manageable server config.

**Revived on 2026-09-07** after a backlog triage found this issue is the shared prerequisite for several settings tickets that would otherwise each build their own editing screen. Scope below is restated against what the app-config stack has actually landed since this issue was parked.

## What the app-config stack already gives us

The live stack is FR-3605 (v2 `{theme, branding`} appearance document) -> FR-1964 (serve the domain appearance document, unify the theme bootstrap) -> FR-3834 (theme family to userConfig, Branding edits to app config).

- **Arbitrary settings keys need no backend work.** Three config names are registered (`userConfig`, `domainConfig`, `publicConfigByDomain`) and each document's `config` is a free-form `JSON!`. A new subKey inside them is a frontend-only decision. Only a brand-new top-level config name needs superadmin provisioning (`adminCreateAppConfigDefinition` + `adminCreateAppConfigAllowList`) — runtime provisioning, not a code change.
- Exception: the `appearance` subKey is validated by `resources/theme.schema.json` (`additionalProperties: false`), so branding-shaped fields must extend that schema.
- Read paths differ before and after login: Relay `myAppConfigs` when authenticated, `publicConfigByDomain` via `POST /func/v2/app-config/public/get` anonymously. The whole surface requires manager >= 26.9.0.

## Scope (remaining)

- [ ] **Inventory** existing WebUI settings — personal user settings and the webui-related keys in `config.toml`.
- [ ] **Personal settings storage**: migrate `useBAISettingUserState` / `SettingAtomFamily` off localStorage (`backendaiwebui.settings.user.*`) onto `userConfig`. Keep the hook API unchanged for consumers — a storage-layer change only. Note FR-3834 moves **only** `themeFamily`; everything else still lives in localStorage and the two stores currently coexist.
- [ ] **`config.toml` settings**: wire the webui keys to be served through app config. FR-1964 covers the appearance document only.
- [ ] **A shared settings editing UI** — the reason this issue was revived. Today there is a read path (`useDomainAppConfig`) but no generic way for an admin to view or edit an app-config value.
- [ ] **DOMAIN-scope write path**: the stack currently exposes `useUpdatePublicDomainAppConfig` (PUBLIC scope) and `useUpdateMyUserAppConfig` (own USER scope) only. `useDomainAppConfig` is read-only, so a DOMAIN-scoped setter plus a `domainConfig`@DOMAIN allow-list entry is needed before any domain-level setting can be edited.

## Why this is the prerequisite

Without a shared editing surface, each of these has to build its own settings screen, which is most of their cost:

- FR-1739 — hide/edit agent statistics items (network RX/TX)
- FR-1815 — SuperAdmin configures the upload chunk size (needs the DOMAIN-scope setter above)
- FR-3467 — config to hide the model `definition.yaml` path

## Related prior work

- FR-59 — Migrate user preferences from localStorage to manager (closed as duplicate of FR-3834 on 2026-09-07; the storage-migration approach for personal settings is the same)
- FR-74 — Setting configs in UI (config.toml + localStorage settings unification and UI)

JIRA Issue: FR-3435

Start by inventorying the WebUI settings and reading useBAISettingUserState, SettingAtomFamily, config.toml, and useDomainAppConfig. Trace the existing user and public app-config hooks, then define the shared editing surface and DOMAIN write path. Done means personal settings and webui config.toml keys use app config, with an editing UI and domain-level updates available.

Written by the indexing model from the issue text.