prayer-times: location + timezone foundation

Goal

Implement location + timezone foundation for prayer-time lookup with reliable fallbacks.

Depends On

• Provider decision in #9 (AlAdhan primary, community fallback optional)

Scope

• Foreground location permission flow.
• Resolve coordinates (lat/lng) and timezone.
• Reverse-geocoding or location label (city/country) for user context.
• Permission denied and permanently denied flows.
• Manual location fallback (city/country input) when GPS unavailable.
• Persist user location preference and timezone metadata in Firestore profile.

Technical Requirements

• Output model from this issue must satisfy both providers:
  • AlAdhan requests (city/country and coordinate modes)
  • Future EzanVakti adapter needs (country/city/district id path)
• Persist minimum fields:
  • latitude, longitude
  • timezone
  • city, country
  • source (gps or manual)
  • updatedAt
• Default calculation method for Turkey should be carried as method=13 downstream (configured in issue #11/#15).

Acceptance Criteria

• App requests location permission and handles all states gracefully.
• App can determine lat/lng + timezone for prayer lookup.
• Manual city/country entry works when location is denied/unavailable.
• Stored profile data is reused on next launch.
• Errors are explicit and non-blocking.

Task Checklist

• Add location service abstraction.
• Add permission state handling (granted/denied/permanently denied).
• Add timezone resolver.
• Add manual location form + validation.
• Add Firestore profile persistence for location metadata.
• Add unit/widget tests for denied/manual flows.

Test Cases

• Permission granted -> GPS location resolved.
• Permission denied -> manual flow displayed.
• Manual city/country -> metadata persisted.
• App restart -> saved location reused.
• Invalid manual input -> validation error.

References

• #9
• https://api.aladhan.com/v1/documentation/openapi/prayer-times/yaml

Start by resolving the provider decision in #9 and reading the referenced AlAdhan API documentation. Then map the Flutter entry points for location permissions, manual input, and Firestore profile persistence; add the requested unit/widget tests for denied, manual, restart, and invalid-input flows. Done means all listed acceptance criteria and test cases pass.