fix(nodes): dispose map timers with their owning view

[n30nex]

Red commit: 2f1a50e (local Chromium: 2 passed, 7 assertion failures). Ownership regression: 059ab49 (9 passed, 4 assertion failures). CI: run awaits maintainer approval (action_required); 0 jobs started.

Rapid navigation or closing node detail could leave a delayed resize targeting a removed or replacement map. Disposal now cancels its timer, each resize captures its own map, and delayed responses respect the view owning the current map. Stale side-pane responses are ignored before rendering.

Fixes #1972.

• E2E assertion added: test-issue-1206-resize-observer-leak-e2e.js:216 and :292. This existing CI-selected suite covers navigation, replacement deadlines, close/Escape, no-location rendering, and late error/success responses. Existing observer-growth assertions remain intact; readiness waits replace fixed sleeps.
• Browser verified: local fixture with real Chromium and Leaflet; 13 browser checks passed after push. Evidence: data/node-map-validation/post-push-browser.log and data/node-map-validation/evidence.md.
• Validation: frontend unit suites 99/18/666 passed; JavaScript syntax, CSS variables, whitespace, PII and XSS checks passed. Backend unchanged; Go suites not rerun.
• Independent adversarial, expert and TDD reviews found no required changes. Two original navigation checks initially timed out; the unchanged parent rerun passed 13/13 (parent-browser-confirm.log).
• Performance/config: one timer handle, no packet/node loops or new requests. Tests enforce zero stale invalidations and one resize at the surviving map's deadline. Existing 100ms delay retained; no new settings or throughput claim.

Fix commits: 2492a65, 1dc090d.

Preflight overrides

• External run-all.sh is unavailable. Scoped branch, red/green, PII, CSS, XSS and whitespace checks were run directly; no migrations, SQL attribution or image markup are added.

[efiten]

Merging. CI had never run on this (stuck in action_required, now approved) and came back green.

removeDetailMap(owner) guarding on owner.contains(detailMap.getContainer()) is the part worth pointing at. A destroy handler that tears down whatever is currently in the module-level variable will happily destroy the next view's map when an old teardown lands late, and that failure looks like a blank map on a fresh navigation, not like a leak. Checking that the map you are about to remove actually belongs to the view being destroyed is what makes this safe under fast navigation.

Clearing the resize timer in the same place matters for the same reason: a pending setTimeout holding a captured map reference keeps both the timer and the Leaflet instance alive past the view.

Verified together with #1969 and #1968 on current master: clean merge, disjoint hunks, eslint clean, frontend suite 666 passed 0 failed.

That is all seven of your PRs reviewed or merged today. Thank you for citing a red commit and its assertion count on each one; being able to see that the test failed before the fix, without reconstructing it, made these considerably faster to review than they would otherwise have been.