Use runtime app metadata for analytics and alarm device registration

[jjoonleo]

Problem

appVersion is hardcoded in both product analytics and alarm device registration paths, so telemetry and backend alarm device metadata can drift from the actual released build. The drift already exists: pubspec.yaml declares 1.0.1+1, while both call sites still report 1.0.0.

Evidence

• pubspec.yaml declares version: 1.0.1+1.
• lib/core/services/product_analytics_service.dart passes appVersion: '1.0.0' into product usage analytics parameters.
• lib/data/repositories/alarm_repository_impl.dart builds AlarmDeviceInfo with appVersion: '1.0.0'.
• lib/data/models/alarm_device_model.dart serializes that value to the backend as appVersion.
• test/data/repositories/alarm_repository_impl_test.dart locks the stale literal into repository behavior.

Proposed direction

Introduce a small injectable app metadata provider under lib/core/services/ that resolves the current app version/build from runtime build metadata, then inject it into ProductAnalyticsService and AlarmRepositoryImpl.

Keep platform/OS metadata behavior explicit, but remove source-level version literals from analytics and alarm registration code. Update tests to verify that supplied runtime metadata flows into analytics parameters and alarm device payloads.

Acceptance criteria

• Product analytics emits app_version from runtime app metadata, not a hardcoded string.
• Alarm device registration sends AlarmDeviceInfo.appVersion from the same metadata source.
• Tests cover the metadata provider path and no repository/service test asserts the current app version as literal 1.0.0.
• Android, iOS, and web behavior is supported or has an explicit documented fallback.
• flutter analyze and targeted analytics/alarm repository tests pass.

Source: Codex codebase audit on 2026-06-28.