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
Adds new widget lifecycle/DOM integration to MapboxOverlay that mutates widget.props._container and manages Mapbox controls; regressions could show up as leaked controls, incorrect positioning, or widget rendering issues across setProps/interleaved modes.

Overview
Adds first-class widget support in MapboxOverlay by adapting deck.gl widgets into Mapbox/MapLibre controls. Widgets with viewId: 'mapbox' are now wrapped in a new DeckWidgetControl and added via map.addControl, so they render inside the map’s native control containers (and avoid overlapping the overlay container).

MapboxOverlay now processes widgets before Deck initialization and before deck.setProps, reusing/removing controls by widget id (and only recreating when placement changes) and cleaning them up on onRemove. Tests and mocks were updated to cover widget/control behavior and to stabilize GL usage in overlaid tests.

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

[coveralls]

coverage: 91.05% (+0.02%) from 91.033%
when pulling 287b467 on chr/mapbox-widget-support
into 32c5d8d 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.