frontend: Clean up MAVLink refresh rates on leave (store + vehicle setup)

[joaoantoniocardoso]

Summary

• Track per-message rate claims in the mavlink store and apply max(claims) (idle 1 Hz) so one consumer can leave without overriding another.
• Vehicle setup / MainView / compass: release rate claims on destroy, discard position listeners, clear CompassDisplay render interval + GSAP tweens.

Test plan

• Visit Home (ATTITUDE 10 Hz) then leave: rate drops to 1 Hz
• Open compass configure, leave: render interval stops; IMU/ATTITUDE rates drop when no other claimant remains
• Gyro calib mount/unmount does not leave 10 Hz streams forever
• Level horizon dialog open/close does not fight CompassDisplay ATTITUDE rate while both tabs are alive
• Gyro calib + CompassDisplay overlapping: tearing down Gyro keeps IMU at 10 Hz while CompassDisplay is mounted

---

Supersedes #4031 (recreated from fork joaoantoniocardoso/BlueOS-docker instead of same-repo head).

[github-actions]

@review.md

[Williangalvani]

• 1.1 [minor] core/frontend/src/store/mavlink.ts:34-49 — the store still has no reference counting: beforeDestroy in one component can lower a rate that another live component depends on. The PR papers over one instance in LevelHorizonCalibration.vue, but the same class of bug remains latent — for example, GyroCalib.beforeDestroy ratchets RAW_IMU/SCALED_IMU2/SCALED_IMU3 down to 1 Hz, and those exact three messages are also requested by CompassDisplay at 10 Hz. If a caller ever has both mounted concurrently (Vuetify's v-tabs-items cache, a dashboard widget, etc.) the surviving component silently drops to 1 Hz. Not a blocker for this PR, but worth tracking — a real fix would keep a per-message subscriber map and pick max(rate).

Could we do this instead? that would take some more code, but we wouldnt override other's rates

[joaoantoniocardoso]

• 1.1 [minor] core/frontend/src/store/mavlink.ts:34-49 — the store still has no reference counting: beforeDestroy in one component can lower a rate that another live component depends on. The PR papers over one instance in LevelHorizonCalibration.vue, but the same class of bug remains latent — for example, GyroCalib.beforeDestroy ratchets RAW_IMU/SCALED_IMU2/SCALED_IMU3 down to 1 Hz, and those exact three messages are also requested by CompassDisplay at 10 Hz. If a caller ever has both mounted concurrently (Vuetify's v-tabs-items cache, a dashboard widget, etc.) the surviving component silently drops to 1 Hz. Not a blocker for this PR, but worth tracking — a real fix would keep a per-message subscriber map and pick max(rate).

Could we do this instead? that would take some more code, but we wouldnt override other's rates

Done; that's indeed a better approach, thanks.