fix(render_map_tool): apply baseStyle changes on render, not just construction

[mattpodwysocki]

Summary

• render_map_tool's baseStyle (e.g. "standard-satellite") was silently ignored on every real call. It was only ever applied at map-construction time from a server-embedded #initial-data script tag, but MapAppUIResource never actually passes initialData when serving the map HTML — so that tag is always empty, the map always constructs with the default "standard" style, and the real payload (with baseStyle) arrives later via the ui/notifications/tool-result → render(payload) path, which never handled baseStyle at all (only baseMapConfig color/theme properties).
• Caught live in Claude Desktop: requesting a baseStyle: "standard-satellite" render produced a map correctly labeled "satellite view" that was still the standard vector style underneath.
• render() now detects when payload.baseStyle differs from the style the map is currently on and switches via map.setStyle(...), deferring the rest of the render (layers/markers/camera/etc.) until style.load fires — matching how a style swap normally works in GL JS, since it replaces sources/layers.

Test plan

• Added a regression test reproducing the original bug (baseStyle arriving via a tool-result render, not initial data — the actual real-world path) — confirmed it fails without the fix (git stash the source change, rerun, see setStyleCalls come back empty)
• Added a test confirming setStyle is not called when a render repeats the already-active style (no-op case)
• npx vitest run — full suite, 947 tests pass
• npx tsc --noEmit — clean

🤖 Generated with Claude Code

[ox-security]

OX Security reviewed this pull request — nothing to fix.

✔ No issues found

Branch fix-render-map-basestyle-switch → main

View scan in OX Security →