[Bug]: CarPlay free-drive: speedLimitView container stays hidden despite valid speed-limit data and camera in .following

Nobody has claimed this yet.

### Mapbox Navigation SDK version

3.26.x (Maps 11.26.x)

### Steps to reproduce

(Visibility rules introduced in 3.25 via the CarPlay speed-limit positioning/visibility update — CarPlaySpeedLimitViewConfiguration.shouldHideSpeedLimitView / CarPlaySpeedLimitViewVisibilityCoordinator)

Connect CarPlay and show the app on the map (free drive / browsing — no active turn-by-turn guidance).
Ensure free drive is running so map-matching provides speed limits (locationMatching / MapMatchingState has non-nil speedLimit).
Drive on roads with known posted limits (Vienna Convention signs).
Observe whether Mapbox’s CarPlay SpeedLimitView appears.
(Optional) Start active navigation on a similar stretch and compare.

### Expected behavior

When speedLimit / signStandard are available and the navigation camera is in .following (and the user is not panning/previewing), the speed-limit sign should become visible after Mapbox’s short reveal delay (~0.2s), same as during active guidance.

### Actual behavior

On free-drive, the private speedLimitViewContainer remains isHidden = true for the entire session (10+ minutes in our log), even though:

SpeedLimitView.speedLimit updates correctly (e.g. 30 / 50 / 70 km/h)
signStandard = viennaConvention
SpeedLimitView.isHidden goes false when data is present (canDraw OK)
isAlwaysHidden = false
navigationCamera.currentCameraState = following
So the view has data and would draw, but the container never unhides. Our own speed pill (fed from navigation().locationMatching → MapMatchingState.currentSpeed / speedLimit) correctly turned red when over limit, confirming the data path is fine.

When we later started active navigation, we saw container.isHidden true → false almost immediately, and the sign stayed visible for the rest of the drive.

This matches shouldHideSpeedLimitView keeping the container hidden — most likely areCarPlayControlsVisible stuck true (safe-area top/horizontal growth vs. the 38pt threshold on layouts) or another chrome input that does not clear in free-drive, while active navigation somehow re-evaluates and reveals the container.

Reproduced in a real vehicle (not only simulator).
Same road segments had shown the sign previously / showed it again under active guidance.
KVO on speedLimitView.isHidden vs speedLimitView.superview?.isHidden separates data-layer hide from chrome-layer hide; only the container stays stuck.
Happy to share anonymized diagnostic log lines (timestamps + containerHidden / speedLimit / camera / upcoming safe-area fields).

### Is this a one-time issue or a repeatable issue?

repeatable

Start with CarPlaySpeedLimitViewConfiguration.shouldHideSpeedLimitView and CarPlaySpeedLimitViewVisibilityCoordinator, then trace how free-drive camera, speed-limit data, and safe-area or CarPlay-control inputs affect the container. Reproduce in CarPlay free drive and compare with active guidance, observing speedLimitView.isHidden separately from its container. Done means the container reveals after the expected delay when valid data and a following camera are present.

Written by the indexing model from the issue text.