Load the optional session Map on demand without interrupting chat

[HomenShum]

A visitor using chat and the default entity List previously downloaded the optional spatial Map renderer at startup. Load it only after Map is selected and session data exists. A local loading status and error boundary preserve List, chat, earlier answers and Stop/Retry if the renderer is slow or unavailable.

On unchanged assistant-ui 0.14.14, initial JavaScript falls from 189,429 to 152,849 gzip bytes (19.3%). First Map adds 37,554 bytes; cumulative JavaScript is 190,403 bytes, a 974-byte split overhead. Three alternating cold Chrome trials under the same 100 ms / 1.6 Mbps / 4× CPU profile give median editable-composer readiness 1,663.2 → 1,467.5 ms. These are small controlled local samples with external fonts blocked, not field Core Web Vitals.

Validation:

• 117 tests; build including TypeScript and library declarations; source/tour citations; secret scan.
• Eight production-browser scenarios at 1440×900 and 375×812: real local answers, 20 view toggles, one renderer request, delayed/failed imports, Map before data, keyboard List recovery and retained answers through Stop/Retry.
• The browser regression fails against the unchanged baseline because selecting Map makes zero new renderer requests; the same scenario passes after the fix.
• Independent code, simplification and evidence review against the frozen six-file tree.

Reproduce with npm run build then node e2e/graph-map-loading.mjs dist <new-evidence-directory> with Google Chrome installed. Browser scenarios are a separate local check; the existing CI workflow is unchanged.

No dependency, vendor, style, starter, model-refresh or CI changes. PR #20's separate SDK upgrade performance hold remains unresolved. No provider/model calls or production deployment are certified.