Consume preferences from the subscribe_events initial_state snapshot

[bdraco]

What does this implement/fix?

Frontend half of the preferences-in-initial-state plumbing; companion to esphome/device-builder#1479. The preferences snapshot now arrives on the subscribe_events initial_state push, so the app shell applies theme straight from it and sets a prefsLoaded flag rather than waiting on a separate config/get_preferences round trip. Expert mode keeps loading the way it does today; there are no experience-level changes here, that lands on top in a follow up.

Related issue or feature (if applicable):

• N/A

Types of changes

• Bugfix (non-breaking change which fixes an issue) — bugfix
• New feature (non-breaking change which adds functionality) — new-feature
• Enhancement to an existing feature — enhancement
• Breaking change (fix or feature that would cause existing functionality to not work as expected) — breaking-change
• Refactor (no behaviour change) — refactor
• Documentation only — docs
• Maintenance / chore — maintenance
• CI / workflow change — ci
• Dependencies bump — dependencies

Checklist

• The code change is tested and works locally.
• npm run lint passes.
• npm run test passes.
• Tests have been added to verify that the new code works (where applicable).

[Copilot]

Pull request overview

This PR updates the app-shell event subscription flow to consume user preferences from the subscribe_events initial_state snapshot, applying theme immediately from the snapshot and exposing a prefsLoaded context flag so consumers can gate preference-dependent UI without waiting for a separate preferences fetch.

Changes:

• Add preferences: UserPreferences to subscribe_events.initial_state typing and handle it in the INITIAL_STATE event handler (apply theme + set _prefsLoaded).
• Introduce prefsLoadedContext and provide it from ESPHomeApp.
• Update theme-preference loading to stop re-applying theme from config/get_preferences, and add a unit test covering the new initial-state behavior.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
test/components/app-shell/events-initial-state-prefs.test.ts	Adds coverage ensuring INITIAL_STATE applies theme from snapshot and sets _prefsLoaded.
src/context/index.ts	Re-exports the new prefsLoadedContext.
src/context/contexts.ts	Defines prefsLoadedContext for preference-snapshot readiness.
src/components/app-shell/events.ts	Seeds theme + _prefsLoaded from INITIAL_STATE.preferences.
src/components/app-shell/data-load.ts	Stops applying theme from getPreferences() (now only updates expert mode).
src/components/app-shell.ts	Provides _prefsLoaded via prefsLoadedContext from the app shell.
src/api/types/event-subscription.ts	Extends InitialStateEventData to include a preferences snapshot.

[esphbot]

PR Review — Consume preferences from the subscribe_events initial_state snapshot

Clean, well-scoped change that consumes preferences from the initial_state snapshot. No blocking issues — two minor naming/scaffolding suggestions.

Strengths:

• preferences is correctly typed as a required field on InitialStateEventData with a clear docstring, matching the lockstep-deployment convention (no defensive optional/probe — consistent with CLAUDE.md).
• applyTheme is self-contained (only touches localStorage/window/document), so calling it from handleEvent before the rest of host state is seeded is safe; verified no hidden dependency on uninitialized fields.
• The refetch in loadThemePreference is correctly narrowed to expert_mode with an explanatory comment, and the new test asserts both the theme application and the _prefsLoaded flag.
• Test fixture makePrefs matches UserPreferences exactly and makeInitial only sets required fields (others are optional) so it type-checks.

Needs attention (non-blocking):

• prefsLoadedContext is provided but has no @consume consumer yet — deliberate scaffolding per the PR, worth confirming the follow-up is queued.
• loadThemePreference no longer loads the theme; the name and catch comment are now slightly misleading.

---

---

Checklist

• New required field matches backend contract (lockstep)
• No defensive version-skew shims added
• Theme application has no uninitialized-state dependency
• Test covers new behavior
• No dead/unconsumed surface — suggestion ＃1
• Naming reflects behavior — suggestion ＃2

---

Automated review by Kōan (Claude) HEAD=9d32e24 1 min 49s

[esphbot]

No blocking issues found.

[bdraco]

Suggestion #2 (the loadThemePreference name) is addressed in 70fa46c, renamed to loadExpertModePreference since it only refreshes expert_mode now; the misleading comment is reworded too.

Suggestion #1 (prefsLoadedContext provided but not yet consumed): intentional scaffolding. This PR is scoped to "theme + a prefsLoaded gate"; the experience-levels follow-up adds the consumers that hold device-creation and editor surfaces until prefs arrive, so the provider lands here and the follow-up only adds @consume sites. The follow-up is queued.