Let `cameraForBounds` fit against an explicit persistent padding instead of the live transform's padding

User Story

As a developer computing a camera for a set of bounds, I can tell cameraForBounds which persistent padding the destination camera will have, so that I can compute a fit for a padding I have not applied yet without moving the map.

Rationale

cameraForBoxAndBearing reads edgePadding = tr.padding from the live transform and adds the padding option on top. The padding option is documented as "padding to add to the given bounds", and there is no way to say "compute the fit as if the map's padding were X". Two consequences:

• The fit is coupled to the current camera. Computing a camera for a different persistent padding requires jumpTo({padding}) first, which fires move events and cancels a running easeTo / flyTo. #6744 and #4095 are the user-facing symptom of the same coupling: leftover padding from an earlier flyTo gets silently summed into the next fitBounds.
• Wrappers that expose a query like "camera for bounds with this destination padding" cannot delegate to GL JS at all.

MapLibre Native's cameraForLatLngBounds takes the full padding as an argument and never reads it from the live transform, so callers can compute a fit for any destination padding without side effects.

Impact

Without this, computing a fit for a padding that differs from the current one requires mutating the map, and the padding-summing behavior in #6744 has no clean fix path because the fit has no explicit notion of destination padding.

AI Assistance

Fable 5.1 helped audit the GL JS and MapLibre Native sources and draft this text. I reviewed and edited it.