feat(forecast): add confidence indicator from cross-source agreement (#322)

[Orinks]

Summary

Implements forecast confidence indicator (#322).

A confidence score (High/Medium/Low) is computed by comparing key metrics
(temperature spread, precipitation probability) across available forecast sources.

Changes

• forecast_confidence.py: ForecastConfidence model + calculator with documented thresholds
• models/weather.py: forecast_confidence field on WeatherData
• weather_client_base.py: confidence computed in multi-source pipeline
• display/presentation/forecast.py: confidence label in ForecastPresentation and fallback text

Thresholds

• HIGH: temp spread ≤5°F and precip spread ≤15%
• MEDIUM: temp spread ≤10°F or precip spread ≤25%
• LOW: greater disagreement
• Single source: MEDIUM with note

Accessibility

Uses plain-English labels (High/Medium/Low) readable by screen readers.
Confidence rationale is included in fallback text for screen reader users.

Testing

• 55 tests across 3 test files — all pass
• test_forecast_confidence.py: 27 tests for the core model and calculator
• test_forecast_confidence_pipeline.py: 11 tests for WeatherData integration
• test_forecast_confidence_presentation.py: 17 tests for ForecastPresentation surfacing

Closes #322

[Orinks]

Code Review — Forecast Confidence Indicator (#322)

Clean, well-scoped implementation. 55 tests, mypy clean, no workflow artifacts committed. ✅

What's good

• Enum values as plain English (High/Medium/Low) — correct choice for screen reader accessibility; avoids synthesizer-unfriendly abbreviations.
• Edge case handling — zero sources → LOW, single source → MEDIUM with clear rationale, temp-only and precip-only scenarios all handled correctly.
• TYPE_CHECKING guard in weather.py — avoids the circular import between WeatherData and ForecastConfidence cleanly.
• Keyword-only confidence param (*, confidence=None) in build_forecast — good API hygiene, prevents accidental positional misuse.
• Separation of UI strings — confidence_label (concise: 'Confidence: High') for visual display, full rationale in fallback_text for screen readers. Right pattern.
• Test breadth — test_forecast_confidence.py covers boundary values at exactly 5°F and 10°F spread; pipeline tests confirm correct plumbing into WeatherData; presentation tests confirm the label and fallback text surface correctly.

Minor observations (non-blocking)

1. assert s.forecast is not None (line ~97 of forecast_confidence.py) — asserts can be stripped with python -O. Safe here because _valid_sources already filters, but consider a cast or a type-narrowing if instead of assert for production-grade robustness.

2. Thresholds assume °F — the constants (_TEMP_HIGH = 5.0) assume Fahrenheit. If a source ever returns temperature in Celsius, the spread comparison would produce incorrect results. Worth verifying all sources are normalised to °F before this call, or adding a note to that effect in the docstring.

3. No confidence in single-source fetch path — calculate_forecast_confidence is only called in the multi-source pipeline. If there is a separate single-source code path, forecast_confidence will remain None on WeatherData. Not a bug given current architecture, just worth documenting.

Summary

No blocking issues. The feature is solid and directly serves the accessibility use case. Ready to merge.