Custom Lovelace row/card intermittently shows "Configuration error" despite the custom element being defined well before the 2-second whenDefined timeout

### Describe the issue you are experiencing A custom Lovelace entity row (used inside a standard `entities` card, loaded via `frontend.extra_module_url`) intermittently fails to receive its `setConfig()` call after a full page reload with a cold cache and the frontend service worker active. This surfaces as a generic "Configuration error" card, appearing after a consistent ~2 second delay that matches a hardcoded timeout in the compiled frontend bundle. Reproduces in both Chrome and Safari. I've traced this as far as possible from outside HA's source, and the evidence rules out the custom element's own code, and even the browser's native Custom Elements API, as the cause. ### What version of Home Assistant Core has the issue? 2026.7.0 ### What was the last working version of Home Assistant Core? Not a regression as far as I can tell - reproduced across multiple recent point releases while diagnosing. ### What type of installation are you running? Home Assistant Container (also reproduced against a production install) ### Browser information - Chrome 149.0.7827.201 - reproduces with DevTools closed; does NOT reproduce with DevTools open, even after manually re-enabling the Service Worker and cache in DevTools settings - Safari 26.5.2 (21624.2.5.11.8) - reproduces even with Web Inspector open, which is how the diagnostic data below was captured ### Integration causing the issue frontend / lovelace ### Link to integration documentation on our website https://www.home-assistant.io/dashboards/entities/ ### Diagnostics information N/A (frontend-only, no backend diagnostics) ### Example YAML snippet Reproduced on a clean Home Assistant install with only this one custom card added (no other HACS resources/integrations, to rule out interference), using `demo:` for entities. Full dashboard config: ```yaml views: - type: sections sections: - type: grid cards: - type: entities entities: - entity: sensor.outside_temperature type: custom:multiple-entity-row ``` (Custom row registered via a plain `frontend.extra_module_url` script, ~36KB, no external runtime imports - everything bundled into one file.) ### Anything in the logs that might be useful for us? Nothing under normal conditions - that's the core problem. No console error, no failed network request, no uncaught exception. Only visible via instrumentation added directly to the custom element (details below). **Reproduction note:** happens in both Chrome and Safari, but Chrome's DevTools appears to change enough browser behavior/scheduling to suppress it entirely, even after manually re-enabling the Service Worker and cache in DevTools settings (Network tab's "Disable cache" off, Application -> Service Workers' "Bypass for network"/"Update on reload" off). Safari's Web Inspector doesn't have this suppression effect, which is how I was able to capture the diagnostic data below live. Safari's inspector itself didn't surface any additional diagnostic information beyond what the custom element's own instrumentation captured. ### Additional information I maintain a HACS custom entity row (`multiple-entity-row`) and have been chasing an intermittent "Configuration error" report from users, reproducible in my own local testbed under these specific conditions: - Cold/full page reload (not a soft in-app navigation) - The frontend's service worker and HTTP cache genuinely active - Intermittent - doesn't happen on every reload - A consistent, noticeable pause of roughly 2 seconds before "Configuration error" appears on screen, when it does happen **Diagnosis steps (all from the custom row's own code - I don't have visibility into frontend-internal source beyond the compiled/minified bundle):** 1. The ~2 second visible delay matches a hardcoded timeout I found in the compiled bundle, in the function used to resolve custom row/card elements: ```js return new Promise((resolve, reject) => { setTimeout(() => reject(new Error(`Custom element not found: ${tagName}`)), 2000); customElements.whenDefined(tagName).then(() => resolve(customElements.get(tagName))); }); ``` 2. Added `performance.now()` timestamps, persisted to `localStorage` (to survive reloads where Chrome DevTools wasn't open, since it being open at all seemed to suppress the bug there - Safari's inspector doesn't have this effect, see Browser information above), at the top of the custom element's module body and immediately after its own `customElements.define(...)` call. On failing reloads, the element consistently registers in ~25-30ms - nowhere near the 2000ms budget. 3. Added logging inside the row's own `setConfig()` and `render()` methods (wrapped in try/catch, to rule out a silently-swallowed exception). On a failing reload, neither is ever called - no error thrown, nothing. 4. To directly verify "defined" really does mean "resolvable" rather than relying on inference, added two more checks immediately after `customElements.define(...)`: - `customElements.get('multiple-entity-row')` - confirms the registry entry actually exists - the element's own fresh call to `customElements.whenDefined('multiple-entity-row')` - times how long that promise itself takes to resolve On a reproduced failing reload (captured live in Safari with Web Inspector open), both resolved in ~23ms, essentially instantly. This confirms the browser's native Custom Elements registry and `whenDefined()` mechanism work correctly for this tag, at this point in time. Despite that, the frontend still waited the full ~2 seconds and then gave up, without ever calling `setConfig()`. Given the element is registered and independently confirmed resolvable via the same native API almost immediately, but HA's own row-creation code still hits its 2-second timeout and never calls `setConfig()`, the issue must be in whatever code path HA uses to await/observe the element's definition - possibly referencing a different `CustomElementRegistry` instance (e.g. a scoped registry) than the global one the element registers against, or some other logic error independent of actual element-registration timing. I don't have access to trace further without frontend source access. Happy to provide the instrumented build, full `localStorage` log captures, or add further logging if useful. This is intermittent and environment-dependent, so I don't have a 100%-reliable minimal repro, but wanted to report given how conclusive the evidence is in ruling out the custom element's own code and the standard Custom Elements API.