docs(frontend): tenant self-service branding editor on dashboard + theming pages (#234)

Applied from PR #234 (changelog hunk dropped - already covered by #236).
Upstream: fullstackhero/dotnet-starter-kit#1329 (merged).

Co-Authored-By: Marcelo M. Maciel <4993482+marcelo-maciel@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: 3 people

src/content/docs/frontend/dashboard.mdx

@@ -1,6 +1,6 @@
 ---
 title: Tenant dashboard
-lastUpdated: 2026-06-11
+lastUpdated: 2026-07-13
 description: The end-user-facing React + Vite app at clients/dashboard - catalog, chat, files, tickets, invoices, identity admin, plus real-time SignalR + SSE feeds.
 sidebar:
   label: Tenant dashboard
@@ -46,7 +46,7 @@ clients/dashboard/src/pages/
 ├── identity/          Tenant-scoped admin: users, roles, groups (+ detail pages)
 ├── invoices.tsx       Invoice list + invoice-detail.tsx
 ├── subscription.tsx   Current plan + billing status
-├── settings/          Profile, security (2FA), appearance, notifications, API keys
+├── settings/          Profile, security (2FA), appearance, branding, notifications, API keys
 ├── system/            Sessions, trash (recycle bin) - plus health + audits routes
 ├── tickets/           File ticket, list, detail, comments
 ├── impersonation-ended.tsx   Graceful landing when an operator grant ends
@@ -65,7 +65,7 @@ A few notes:
 
 The dashboard's appearance system is **per-user**: light/dark/system mode, an accent colour (presets or a custom hue), font, density, and reduced motion - all stored in localStorage and applied via CSS custom properties (Settings → Appearance). The neutral chassis is deliberately untinted so the accent does the branding work.
 
-Per-**tenant** branding lives server-side as the Multitenancy module's `TenantTheme` (palette, brand assets, typography, layout) with a permission-gated editor in the admin console. Full details: [theming](/docs/frontend/theming/).
+Per-**tenant** branding lives server-side as the Multitenancy module's `TenantTheme` (palette, brand assets, typography, layout). A tenant admin edits their **own** tenant's brand from **Settings → Branding** (light + dark palettes + logo/favicon URLs, with a live preview and reset-to-defaults) - the tab is permission-gated on `Tenants.UpdateTheme` and the calls are current-tenant-scoped (no `tenant:` header). Operators can still edit any tenant's brand from the admin console. Full details: [theming](/docs/frontend/theming/).
 
 ## Chat - the realtime showcase
 

src/content/docs/frontend/theming.mdx

@@ -1,6 +1,6 @@
 ---
 title: Per-tenant theming
-lastUpdated: 2026-06-11
+lastUpdated: 2026-07-13
 description: How tenant branding works in the kit - the TenantTheme aggregate in the Multitenancy module, the admin branding editor, and the dashboard's per-user appearance system.
 sidebar:
   label: Theming
@@ -14,10 +14,10 @@ seo:
 
 Theming in the kit has two layers that are easy to conflate, so let's name them up front:
 
-1. **Per-tenant branding** - the Multitenancy module owns a `TenantTheme` aggregate (colour palettes, brand assets, typography, layout) with permission-gated read/update/reset endpoints and an editor in the admin console. Themes are **data, not deploys** - editing one never requires a rebuild.
+1. **Per-tenant branding** - the Multitenancy module owns a `TenantTheme` aggregate (colour palettes, brand assets, typography, layout) with permission-gated read/update/reset endpoints. Two editors write it: operators edit any tenant from the admin console, and a tenant admin edits their **own** tenant from the dashboard's **Settings → Branding** (gated on `Tenants.UpdateTheme`, current-tenant-scoped). Themes are **data, not deploys** - editing one never requires a rebuild.
 2. **Per-user appearance** - the dashboard ships a rich appearance system (light/dark/system mode, accent colour, font, density, reduced motion) that each **user** controls from Settings → Appearance and that persists in localStorage.
 
-The `TenantTheme` store + editor are fully wired end-to-end on the backend and admin side. The dashboard does **not yet** read `TenantTheme` to repaint its chrome per tenant - its visual identity today comes from the per-user appearance system. If you want full white-label rendering, the wiring point is small and described [below](#rendering-tenanttheme-in-your-own-frontend).
+The `TenantTheme` store + both editors are fully wired end-to-end. What's **not yet** wired is *rendering*: neither app reads `TenantTheme` to repaint its chrome per tenant - visual identity today comes from the per-user appearance system, and the dashboard's Branding tab edits the stored theme without yet consuming it for its own paint. If you want full white-label rendering, the wiring point is small and described [below](#rendering-tenanttheme-in-your-own-frontend).
 
 ## The `TenantTheme` model