Add Branding Support

[jbouder]

Summary

Add branding support to this app, which currently has none, adopting the same baseline as nebari-dev/nebari-landing: Helm values.yaml branding rendered into a
runtime /config.json that the frontend reads at startup, with built-in Nebari defaults. As with the landing app, this must also support running outside Kubernetes via a local config file / env vars /
defaults. This introduces a branding config schema, the runtime config delivery to the frontend, and the deployment/packaging wiring.

Motivation

• This app has no branding mechanism today; operators cannot customize title, logo, or theme without code changes
• Reusing the nebari-landing baseline gives a consistent branding experience and config shape across Nebari apps
• Runtime config.json injection decouples branding from the build — no image rebuild to rebrand
• Supporting non-k8s execution keeps local dev and standalone deployments working without a Helm chart
• Starting from the shared baseline avoids inventing a divergent, one-off branding system

Acceptance Criteria

• Branding config schema mirrors nebari-landing's frontend.branding block (title, logoUrl, faviconUrl, theme.light, theme.dark)
• Helm chart renders branding values into a /config.json served to the frontend
• Frontend loads /config.json at startup, before React mounts, and applies branding
• Theme token values validated at runtime (reject ;, {, }, url(), javascript:, etc.) matching nebari-landing's security handling
• Non-k8s path: branding resolves from a local config file and/or env vars when no chart-rendered config.json is present
• Documented precedence order (e.g. chart-rendered config.json → local file → env vars → built-in defaults)
• Built-in Nebari defaults render when no branding is configured in either mode
• App behaves identically to today when no branding is set (no visual regression for existing deployments)
• Documentation covers both the Helm/k8s and non-k8s configuration paths

Out of Scope

• Designing or sourcing the actual logo/favicon/theme assets
• Branding fields beyond what nebari-landing currently supports (e.g. logoUrlDark, tracked separately)
• Changes to nebari-landing itself — this issue only adopts its baseline here
• Per-user or per-tenant dynamic theming beyond the static operator-configured branding