fix: Clear the initialized condition state when the card is not usable (#2646)

The `initialized` state (used in conditions/triggers) was written once
and never cleared, so it meant "has this card ever been initialized"
while everything reading it took it as "is this card usable now". Home
Assistant takes a card off the page and puts it back whenever its
dashboard tab is left and returned to, so the card initialized again
while the state claimed it was initialized throughout: `trigger:
initialized` fired once per card rather than once per startup, and
automations were dropped in between.

The card lifecycle is now an explicit state machine (`SessionManager`),
the only writer of `initialized`, which separates a card that is
starting up from one initializing part of itself again while it runs. A
new `ever` parameter (conditions/triggers) selects the old latched
behaviour.

`remote_control` uses that parameter to keep its two camera priorities
correct under repeated starts. With `camera_priority: entity` the card
now re-reads the entity every time it starts, so a camera selected while
the card was away is picked up on return. With `camera_priority: card`
the card writes the entity on its first start only, unchanged, since
repeating that write would overwrite a camera the user had selected.

Closes: #2642


BREAKING CHANGE: `condition: initialized` is now `false` whenever the
card is not usable, and `trigger: initialized` fires each time the card
starts up rather than only the first time. Set `ever: true` on either to
keep the previous behaviour.

src/card-controller/issues/issue-manager.ts

@@ -23,7 +23,7 @@ export const RETRY_EXPONENTIAL_MAX_SECONDS = 600;
 
 // Wraps the passive IssueStateManager with reaction logic. A single
 // condition-state listener drives everything: it runs one-shot static detection
-// when mandatory-init completes (`initialized` transitions to true), then
+// when mandatory-init first completes (`everInitialized` becomes true), then
 // evaluates dynamic issues on every subsequent state change, schedules retries,
 // and updates the card. Full-card issues are rendered by card.ts via
 // getStateManager().getFullCardIssue(). Non-full-card issue notifications are
@@ -183,14 +183,14 @@ export class IssueManager {
   // Drives both one-shot static detection (on mandatory-init completion) and
   // normal re-evaluation (on any condition-state change).
   //
-  // `initialized: true` in the change payload means mandatory initialization
-  // just finished -- see InitializationManager._initializeMandatory. That's
-  // also the earliest point at which the full HASS object is guaranteed
+  // `everInitialized` is set when mandatory initialization first completes --
+  // see InitializationManager._initializeMandatory -- and is never cleared, so
+  // this block runs exactly once however many times the card initializes. That
+  // is also the earliest point at which the full HASS object is guaranteed
   // ready for websocket calls (e.g. LegacyResourceIssue's lovelace/resources
-  // fetch). Because `initialized` is latched (its comment notes it never
-  // changes again), this block fires exactly once per IssueManager life.
+  // fetch).
   private _onStateChange(change: ConditionStateChange): void {
-    if (change.change.initialized === true && change.new.hass) {
+    if (change.change.everInitialized === true && change.new.hass) {
       void this._stateManager.detectStatic(change.new.hass).then(() => this.evaluate());
     }
     this.evaluate();

src/card-controller/issues/issues/initialization.ts

@@ -47,7 +47,7 @@ export class InitializationIssue extends AbstractErrorIssue {
   }
 
   public detectDynamic(): void {
-    if (!this._api.getInitializationManager().isInitializedMandatory()) {
+    if (!this._api.getInitializationManager().areMandatoryAspectsInitialized()) {
       return;
     }
     // The success settle: mandatory init completed, so there is no error to show
@@ -88,7 +88,8 @@ export class InitializationIssue extends AbstractErrorIssue {
     // render cycle. destroy() releases the existing CameraManager's held
     // resources (WebSocket subscriptions, listeners) before the CAMERAS
     // init aspect replaces the instance via createCameraManager().
-    this._api.getInitializationManager().uninitializeMandatory();
+    this._api.getInitializationManager().invalidateMandatoryAspects();
+    this._api.getInitializationManager().getSessionManager().end();
     void this._api.getCameraManager().destroy();
     return false;
   }