perf(tracker): batch fused location delivery to cut wakeups

[adsamcik]

Summary

Battery follow-up from the tracking-architecture review (P2). The fused location request never set setMaxUpdateDelayMillis, so the device wakes for every fix even when nobody is looking at the screen.

Change

• Adds setMaxUpdateDelayMillis(interval × 3) to the fused LocationRequest in both onEnable and updateInterval, refactored into a shared buildLocationRequest(...) helper (removes duplication).
• This lets the OS batch several fixes and deliver them together when power-efficient (typically screen-off / Doze-adjacent windows), cutting radio + CPU wakeups. While the app is interactive the platform still delivers promptly.
• Safe by construction: onNewData already accepts a List<Location> and filters/persists each fix with its own timestamp, so route reconstruction is unaffected by when a batch is delivered. The 3× factor bounds worst-case delivery latency.

Why a constant factor (and not passive / tier-aware priority)

• AMBIENT tier already uses a non-GPS trigger (AmbientCollectionTrigger), so a "passive listener for AMBIENT" is a separate, more architectural change (tracked as an issue), not a tweak to this trigger.
• Tier-aware Priority (e.g. LOW_POWER for ECONOMY) would require threading the tier through DynamicIntervalCollectionTrigger.updateInterval(...); kept out of this PR to stay focused and low-risk.

Verification

• ./gradlew :tracker:engine:compileDebugKotlin — BUILD SUCCESSFUL.

Notes

Draft — opened for review. setMaxUpdateDelayMillis is part of the GMS LocationRequest.Builder already used here.