chore: upgrade mapbox-gl version for accessibility issues (v3.0.0)

[anguyen-yext2]

• current version has some accessibility issues that will be addressed by this upgrade
• removed unnecessary @types/mapbox-gl import since mapbox-gl provides its own types
• replace Mapbox-owned public types in search-ui-react with library-owned, version-stable interfaces
• replace deprecated Mapbox aliases usage

This PR also includes some improvements that I noticed when testing:

• test-site pin popups not showing up
• clean up the map listeners properly
• memoizes the debounced function so it stays the same across renders unless milliseconds changes

J=WAT-5461
TEST=auto,manual

verified test-site still function as expected
verified that locator functions as expected and that there is no longer any accessibility errors on live site

[k-gerner]

Why does this require a major version upgrade?

[semgrep-code-yext]

Legal Risk

The following dependencies were released under a license that
is currently prohibited by your organization. Merging is blocked until this is resolved.

Recommendation

Reach out to your security team or Semgrep admin to address this issue. In special cases, exceptions may be made for dependencies with violating licenses, however, the general recommendation is to avoid using a dependency under such a license

non-standard

• mapbox-gl 3.20.0
• mapbox-gl 3.20.0

[github-actions]

Current unit coverage is 89.1826923076923%
Current visual coverage is 68.85075403016121%
Current combined coverage is 91.55206286836935%

[coveralls]

coverage: 84.457% (-0.2%) from 84.61%
when pulling 6c675f6 on mapbox-upgrade
into 2b50142 on main.

[anguyen-yext2]

Why does this require a major version upgrade?

Because our public types expose Mapbox types (mapboxgl.MapboxOptions, LngLatBounds, etc.), so consumers can see breaking type/runtime differences even though our component props didn’t change.
For example, if a consumer uses our exported OnDragHandler (bounds non-null), but Mapbox v3 can return nullable bounds in some paths, their handler assumptions can fail type checks or require code changes.
That’s why I had to change MapboxMap.tsx around getBounds() handling.
Similarly, consumers would hit TS errors when accessing e.originalEvent until they add guards like 'originalEvent' in e.

[k-gerner]

Generally LGTM

[k-gerner]

Approving but would like a second approval here if we can wait for that