Fix the stale unit tests revealed by the jsdom test-environment migration

[CarsonDavis]

Fix the stale unit tests revealed by the jsdom test-environment migration

Motivation

The test-environment migration (#148) makes the unit suite actually run for the first time — a set of specs that previously errored at import (and silently provided no protection) now execute. With them running, nine cases fail. None of these are caused by the migration; they are tests written against older behavior that were never updated, because the suite never reached them. Now that it does, the failures are visible.

This issue tracks bringing those tests in line with the code's current behavior, so the unit suite is honestly green and the green result means something. It is intended to land as a small PR stacked on top of the #148 migration branch.

What's failing, and why

Two unrelated groups:

1. Panel-manager layout-notification tests (8 cases). These tests assert that registering, removing, resizing, re-stating, or focusing panels fires a browser-level window event with a specific name. The application was refactored to broadcast panel-layout changes over the in-app event bus instead of a window event. The tests still listen for the old window event, so they observe nothing and fail. The fix is to update these tests to observe the current event-bus notification rather than the removed window event.

2. Dashboard config validator test (1 case). This test feeds the validator a tool that is missing both its display name and its icon, and asserts the validator returns two errors — one for the missing name and one for the missing icon. The validator currently reports only the missing name.

Open question (resolve during this work): Is a tool's icon meant to be required or optional?

• If required, the validator is missing a check and should gain one (a product-behavior change), and the test stays as written.
• If optional, the test over-asserts and should drop the icon expectation.

Either resolution is acceptable; pick one deliberately and make the test match it.

Done when

• The unit suite passes fully — no failing specs — both locally and in CI.
• The panel-layout notification tests verify the current in-app event-bus mechanism, not the removed window event, and still meaningfully assert that a layout-change notification fires with the panel data.
• The icon open question is resolved one way or the other, and the validator test reflects that decision.
• The change is limited to test content (and, only if the open question lands on "required," a validator check). The Run the browser-dependent unit tests in a DOM-capable test environment #148 test-runner/environment setup is not modified.

Out of scope

• The test-environment migration itself (Run the browser-dependent unit tests in a DOM-capable test environment #148) — runner, jsdom setup, CI Node bump, import swaps. This issue assumes that is in place.
• Adding new test coverage beyond what's needed to make these existing cases honest.
• Any rework of the end-to-end suite.

Relationship

• Follows from Run the browser-dependent unit tests in a DOM-capable test environment #148. Branch off the Run the browser-dependent unit tests in a DOM-capable test environment #148 migration branch; this is the second of two PRs, split deliberately to keep each one easy to review (migration mechanics vs. stale-test content).
• The Run the browser-dependent unit tests in a DOM-capable test environment #148 migration PR intentionally leaves these 9 tests failing, so its unit CI is red by design until this PR lands. Merge the two together (or this one immediately after), rather than merging the migration alone.

Draft implementation notes — written as of 42b9e0ad on 2026-06-16. Rough guide; re-verify against latest code.

The 9 failing cases

• tests/unit/DashboardConfigValidator.spec.js — "validates tools array correctly" (1)
• tests/unit/panelManager/panelManager.layout.spec.js — "triggers layout recalculation after resize", "dispatches custom event with panel data", "includes all panels sorted by priority in event" (3)
• tests/unit/panelManager/panelManager.registration.spec.js — "triggers layout recalculation after registration", "…after unregistration" (2)
• tests/unit/panelManager/panelManager.stateManagement.spec.js — "…after state change", focusTool "triggers layout recalculation" (2)
• tests/unit/panelManager/panelManager.toolManagement.spec.js — "triggers layout recalculation after removal" (1)

Group 1 — panel layout notifications (the 8 panelManager cases)

Current mechanism (mitt event bus):

• Producer: src/essence/Basics/PanelManager_/PanelManager_.ts — notifyLayoutChanged() calls mmgisAPI.emit('mmgis-panel-layout-changed', { panels }).
• Consumer: src/essence/Basics/UserInterface_/UserInterfaceModern_.js — subscribes with mmgisAPI.on('mmgis-panel-layout-changed', …).
• mmgisAPI.emit is mitt().emit (src/essence/mmgisAPI/mmgisAPI.js). It does not call window.dispatchEvent anywhere — confirmed by grepping the source; the only dispatchEvent(new CustomEvent(...)) hits are in vendored THREE.js devtools shims.

What the tests do (stale):

• tests/unit/panelManager/testHelpers.js exports mockWindowDispatchEvent(), which overrides window.dispatchEvent and collects events into mock.events. The failing cases assert mock.events.length > 0 and mock.events[…].type === 'mmgis-panel-layout-changed'. Since the producer emits via mitt, window.dispatchEvent is never called and mock.events stays empty.

Rough fix: replace the window.dispatchEvent capture with an mmgisAPI.on('mmgis-panel-layout-changed', …) subscription (or assert against the mocked bus). Note the #148 migration already mocks mmgisAPI in these specs (to avoid pulling in the heavy Map_ import chain) via a vi.mock at the top of each panelManager spec; the natural approach is to make that mock a real mitt() instance and assert on its emit/on. The { panels } payload shape (sorted by priority) is what two of the cases check.

Group 2 — validator icon check (the 1 case)

• Test: tests/unit/DashboardConfigValidator.spec.js around lines 138–158 — passes tools: [ { name, icon, js }, { js: 'MissingName.js' } ] and expects errors for both missing "name" and missing "icon" on Tool[1].
• Validator: src/essence/Validators/DashboardConfigValidator.js around lines 106–111 — only pushes errors for a non-string name and a non-string js; there is no icon check.
• Resolution depends on the open question above. If icon becomes required, add the check alongside the existing name/js checks; if optional, drop the icon assertion from the test.

Gotcha

• Do not "fix" Group 1 by reintroducing a window.dispatchEvent/CustomEvent in PanelManager_. The event-bus (mitt) mechanism is the current design; the tests are what's behind, not the product.