Labels with unsupported characters use fallback typeface partially

Nobody has claimed this yet.

**mapbox-gl-js version**: 2.8.2

**browser**: Chrome

### Steps to Trigger Behavior

1. In Studio, open a core style, for example `streets`
2. Navigate to the `place label` component, and set language to `local`
3. Change the primary typeface in the place component to something that is visibly different from the fallback font Arial Unicode MS Regular and has a low script coverage, e.g. Sniglet Extrabold
4. Navigate to these locations and observe the characters:

`#7.35/14.749/109.668`

`#5.65/41.435/53.121`

### Link to Demonstration

[Street style](https://api.mapbox.com/styles/v1/mel-anie/cl2rnm3l7000e14nnexp9i4rz.html?title=copy&access_token=pk.eyJ1IjoibWVsLWFuaWUiLCJhIjoiY2tub3IxbWt0MGFtMjJvcDh5cjU3ZDFseSJ9.npem8MVd2oOJNABA0jzSAQ&zoomwheel=true&fresh=true#6.91/15.084/109.92)

### Expected Behavior
I would expect the entire string to fallback to the fallback typeface Arial Unicode MS Regular that’s defined in the style, like it does in some cases, such as the Arabic script:

### Actual Behavior
It appears that in some cases (Latin script related characters?), only unsupported characters fallback whereas the supported characters stay in the primary font. This makes labels look really odd, in particular if the primary and fallback typeface differ visually, which is the case with some branded customer fonts.

Reproduce the issue in Chrome using the listed Studio steps, styles, typefaces, and map locations, then trace the label font-fallback behavior in the map rendering code. Done means unsupported characters cause the entire string to use the configured fallback typeface, matching the expected Arabic behavior without changing supported-character rendering unexpectedly.

Written by the indexing model from the issue text.