Fix null-safety crashes in location/weather alarm services (remove force unwraps)

[NihalDR]

Problem statement

There are crash-prone null assertions (!!) in Android alarm services that can terminate the app when data is missing or partially returned.

1. Location parsing path

   • File: android/app/src/main/kotlin/com/ccextractor/ultimate_alarm_clock/ultimate_alarm_clock/Utilities/LocationFetcherService.kt
   • Evidence: line ~66 (setLocationString!!)
   • Risk: if flutter.set_location is null or unexpectedly absent, setLocationString!! throws a NullPointerException.

2. Weather response parsing path

   • File: android/app/src/main/kotlin/com/ccextractor/ultimate_alarm_clock/ultimate_alarm_clock/Utilities/WeatherFetcherService.kt
   • Evidence: line ~86 and adjacent checks using response.current?.rain!!, response.current?.windSpeed10m!!, response.current?.cloudCover!!
   • Risk: if response.current or any field is null, forced unwrap triggers NullPointerException.

These are reliability bugs in alarm-critical flows where the app should fail safely, not crash.

Reproduction

Case A: Location preference missing

1. Install and run app on Android.
2. Ensure shared preference flutter.set_location is absent/cleared.
3. Trigger location-based alarm flow that starts LocationFetcherService.
4. Observe crash when service executes setLocationString!!.split(",").

Case B: Partial weather API response

1. Run weather-based alarm flow that starts WeatherFetcherService.
2. Simulate API response where current or one of rain/windSpeed10m/cloudCover is null.
3. Observe crash during weather classification where fields are force-unwrapped with !!.

Expected behavior

• App should not crash when location preference is missing or weather fields are null.
• Service should log a clear warning/error and either:
  • stop gracefully, or
  • choose a safe default behavior (for example, ring alarm instead of suppressing it).

Acceptance criteria

• Remove setLocationString!! and handle null/blank preference safely with guard clauses.
• Remove force unwrap (!!) from weather field checks and use null-safe logic/defaults.
• Add explicit error logging for malformed location string and incomplete weather payload.
• Ensure service lifecycle handles invalid input without throwing runtime exceptions.
• Add tests (or at minimum deterministic validation methods) covering:
  • missing flutter.set_location
  • malformed location string
  • null/partial weather payload

Suggested fix

• Replace non-null assertions with safe handling and early return/error log when required data is missing.
• Refactor parsing/classification into small pure functions to make edge cases testable.