Fix getPaintProperty throwing on unknown paint property names

[akashchamp]

Fixes #6033.

Problem

map.getPaintProperty(layerId, name) throws an unhelpful TypeError when name is not a real paint property for that layer's type, instead of reporting a clear user error:

map.getPaintProperty("background", "fill-radius");
// Uncaught TypeError: Cannot read properties of undefined (reading 'value')

This happens because StyleLayer#getPaintProperty → Transitionable#getValue indexes into its internal property map with the raw (unchecked) name and immediately dereferences .value on the result, which is undefined for an unrecognized property.

Fix

Style#setPaintProperty already guards this same lookup with StyleLayer#isPaintProperty before touching the property map. Style#getPaintProperty did not have an equivalent guard. This PR adds one: before delegating to layer.getPaintProperty(name), it checks layer.isPaintProperty(name) (accounting for the -transition suffix, which StyleLayer#getPaintProperty also special-cases) and, if the name isn't a paint property for that layer's type, fires a descriptive error event and returns undefined instead of throwing — consistent with this project's convention of using error events to report user errors (see CONTRIBUTING.md).

map.getPaintProperty("background", "fill-radius");
// => undefined, and an 'error' event fires with:
// "'fill-radius' is not a paint property of background layers."

Scope note: Style#setPaintProperty currently has a similar unguarded layer.getPaintProperty(name) call of its own (for its dirty-check), which means it can still throw for an unknown property name today, despite the validation described above. That's a separate, narrower bug (previously tracked and closed as #6030) from what this issue (#6033) asks for, so I left it alone here to keep this change focused — happy to follow up separately if that's wanted.

Verification

• Reproduced the crash against current main with a throwaway test calling style.getPaintProperty('background', 'fill-radius') — confirmed it threw Cannot read properties of undefined (reading 'value') before this change.
• Added regression coverage in test/unit/style/style.test.ts (describe('Style#getPaintProperty', ...)):
  • unknown paint property name → no throw, returns undefined, fires an error event whose message matches /fill-radius.*not a paint property/.
  • a valid <property>-transition name (e.g. background-color-transition) still resolves correctly, guarding against a regression in that pre-existing, separately-handled case.
• npm run test-unit -- test/unit/style/style.test.ts — 161 passed, 1 pre-existing skip, 0 failed.
• npm run test-unit -- test/unit/style/style_imports.test.ts test/unit/style/style_layer_index.test.ts test/unit/style/style_layer.test.ts test/unit/ui/map/properties.test.ts test/unit/ui/map.test.ts (paint-property-related tests) — all passed, no regressions.
• npm run tsc — exit 0.
• npm run lint — exit 0.
• Added a CHANGELOG.md entry under Unreleased / Bug fixes per CONTRIBUTING.md.

Launch Checklist

• Make sure the PR title is descriptive and preferably reflects the change from the user's perspective.
• Add additional detail and context in the PR description.
• Write tests for all new functionality and make sure the CI checks pass.
• Document any changes to public APIs. (Behavior-only fix; no signature change.)
• Post benchmark scores if the change could affect performance. (N/A — no rendering/perf-sensitive path touched.)
• Tag @mapbox/map-design-team @mapbox/static-apis. (N/A — no style spec API or visual changes.)
• Tag @mapbox/gl-native. (N/A — no shader changes, no native port needed.)

---

AI disclosure: I used Claude (Anthropic) to help investigate this issue and draft this fix and its tests. I reviewed the change, ran the verification above myself, and stand behind the PR.

[github-actions]

Hey, @akashchamp 👋 Thanks for your contribution to Mapbox GL JS!

Important: This repository does not accept direct merges. All changes go through our internal review process.

What happens next:

1. A team member will review your PR here first
2. If it looks good, they will import it to our internal repository for further review
3. If approved, changes will be synced back here via our release process

Please respond to any review comments on this PR. For more details, see CONTRIBUTING.md.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}