fix(mapbox): automatically inject 'mapbox' view in overlaid mode for multi-view consistency

[chrisgervang]

Summary

Fixes an inconsistency in MapboxOverlay where custom views behave differently in interleaved vs overlaid modes.

Problem

When implementing multi-view examples in #9946, we discovered that when interleaved=false (overlaid mode), the multi-view example did not render airports/arcs layers because there was no 'mapbox' view for them to render in. In interleaved=true mode, the same example worked fine.

Root cause: In interleaved mode, getViewport() in deck-utils.ts automatically falls back to creating a 'mapbox' view when it's not found in custom views. However, in overlaid mode, custom views were used as-is without this fallback, creating inconsistent behavior.

Solution

Added a _getViews() helper method in MapboxOverlay that checks if custom views include a view with id 'mapbox'. If not, it automatically injects the default 'mapbox' view, matching the interleaved mode behavior.

This allows users to only specify additional views (like minimap, ortho) without having to manually include the base map view.

I kept the fallback within getViewport() as a defensive measure.. it shouldn't be needed anymore, but I'm leaving this cleanup for another PR for the sake of keeping this one focused.

Test Plan

• All tests passing. New tests:
  1. AutoInjectMapboxView - No custom views initially, then tests setProps with custom views
  2. AutoInjectMapboxViewWithCustomViews - Custom views provided at construction time
  3. NoDuplicateWhenMapboxViewProvided - Explicit 'mapbox' view provided at construction time
• Verified multi-view examples from feat(basemap-browser): add batched rendering toggle and multi-view examples #9946 now work in both interleaved and overlaid modes

---

Note

Medium Risk
Touches view selection and update paths (setProps, render loop, and style/projection updates), which could affect rendering order or multi-view setups; changes are localized and backed by new tests.

Overview
Fixes multi-view inconsistencies in MapboxOverlay by always ensuring a base-map-synchronized view exists: when custom views are provided without an id of "mapbox", a default MapView/GlobeView with id "mapbox" is auto-injected (including on setProps, render updates, and projection/style changes).

Adds tests to verify auto-injection, setProps behavior, and no-duplicate behavior when an explicit "mapbox" view is supplied, and updates docs to clearly document the "mapbox" view-id convention for layerFilter and custom view ordering.

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

[coveralls]

coverage: 91.091% (+0.002%) from 91.089%
when pulling 9615b35 on mapbox-overlay-view-injection
into 6149b4c on master.

[cursor]

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

[chrisgervang]

To use #9948

[chrisgervang]

I'm considering a few paths here..

1. inject the mapbox view into views when it isn't present in every usage at runtime in MapboxOverlay.
   Pros: this is the pattern we do for parameters and keeps the data flow uni-directional. It's predictable.
   Cons: need to maintain coverage on all setProps usages

2. (current solution) somehow insert the view internally in getViewport in the overlaid case. We can currently do this in interleaved since
   Pros: Works for interleaved since it calls deck._drawLayers directly
   Cons: Overlaid does call deck._drawLayers currently since all drawing is handled internally. Overlaid would have to be done using a different hook or diverge from how interleaved works

3. Always require the user to provide a MapView({id: 'mapbox'}) or GlobeView({id: 'mapbox'}) when they're supplying the views prop
   Pros: simplier internals
   Cons: the user is responsible for understanding internal workings and interactions between maplibre and deck.. there also isn't much benefit to them because they

[chrisgervang]

For context, this is what is not true for overlaid mode that this PR aims to fix