v1.54.2: HP-1541-01 — vacuum selected_map fallback obeys the not-nullish map-id contract

The v1.54.1 contract (first not-None value wins, zero is a value) covered
the source entity but not the card's fallback on the vacuum's own
selected_map: _vacMapId still used truthiness, so selected_map: 0 became
'default' on the frontend while trails.py resolve_map_id stored the run
under '0'. Calibration and server trails split across two keys and the
recorded run never rendered after reload.

The fallback is now the shared pure helper vacMapIdWithFallback (nullish
check), mirroring resolve_map_id. Cross-runtime regressions added for
selected_map = 0, '0' and '' on both sides; the frontend cases fail on the
old truthiness code.

src/vacuum.ts

@@ -94,6 +94,19 @@ export function vacMapIdFromAttrs(attrs: Record<string, any>): string {
   return String(attrs.map_name ?? attrs.current_map ?? attrs.map_index ?? attrs.selected_map ?? 'default');
 }
 
+/**
+ * The card-side fallback half of that contract (HP-1541-01): when source
+ * telemetry names no map ('default'), the vacuum entity's own selected_map
+ * decides — under the SAME not-nullish rule as above. The old truthiness
+ * check in _vacMapId turned `selected_map: 0` into 'default' while the
+ * server recorder (trails.py resolve_map_id) stored the trail under '0', so
+ * calibration and saved runs lived under a key the renderer never matched.
+ */
+export function vacMapIdWithFallback(teleMapId: string, selectedMap: unknown): string {
+  if (teleMapId !== 'default') return teleMapId;
+  return selectedMap != null ? String(selectedMap) : 'default';
+}
+
 /**
  * Normalise the attribute zoo. One parser instead of per-brand classes: the
  * three Tier-A integrations (Xiaomi Cloud Map Extractor, Tasshack