feat(mapbox): Add widget support to MapboxOverlay via IControl adapter

[chrisgervang]

Closes #9962

Background

Enable deck widgets to coexist with native Mapbox/MapLibre controls without DOM overlap by rendering widgets with viewId: 'mapbox' into the map's control container system via the new _container prop.

Change List

• Add DeckWidgetControl class that wraps deck widgets as Mapbox IControls
• Process widgets with viewId: 'mapbox' in MapboxOverlay, automatically wrapping them as IControls
• Set widget.props._container to Mapbox-positioned element so WidgetManager appends there
• Widgets stack correctly with native controls in the same DOM container, preventing overlap

---

Note

Medium Risk
Changes overlay lifecycle behavior by mutating widget _container and dynamically adding/removing Mapbox controls, which could impact widget rendering/cleanup and control ordering across setProps and mode switches.

Overview
Adds Mapbox/MapLibre control integration for deck.gl widgets: widgets with viewId: 'mapbox' are now wrapped as IControls so they render inside the map’s native control containers (avoiding DOM overlap with built-in controls).

MapboxOverlay now creates/updates/removes these widget-controls on onAdd, setProps, and onRemove, reusing controls by widget id (and only recreating on placement change) while still passing widgets through to Deck for event handling. Tests and mocks are extended to cover widget behavior and control positioning, and overlaid-mode tests use an isolated WebGL device to avoid shared context issues.

^{Written by Cursor Bugbot for commit 79355a6. This will update automatically on new commits. Configure here.}

^{Cursor Bugbot found 1 potential issue for commit 79355a6}

[coveralls]

coverage: 91.108% (+0.02%) from 91.091%
when pulling 79355a6 on chr/mapbox-widget-support
into 1510545 on master.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

[cursor]

Placement change undetected for mutated widget objects

Low Severity

The placement comparison existingControl.widget.placement === widget.placement fails to detect placement changes when the same widget object is passed with a mutated placement property. After setWidget(widget) is called in a previous iteration, existingControl.widget becomes the same reference as the current widget. When both sides of the comparison reference the same object, the comparison is trivially true regardless of whether placement was actually changed. The control remains in its original map position even though the widget's placement changed.