feat: Handle PW/WMO alert cancellation lifecycle

[Orinks]

Summary

The current alert cancellation logic relies on NWS-specific cancel references (CAN message types fetched from the NWS API). Pirate Weather's WMO alerts don't have this mechanism — alerts simply disappear from the API response when cancelled or expired.

Current Behavior

• NWS alerts: diff_alerts() uses confirmed_cancel_ids from _fetch_nws_cancel_references() to verify genuine cancellations vs. transient API gaps
• PW/WMO alerts: No cancel reference verification. When an alert disappears from the PW response, it's unclear if it was genuinely cancelled or if the API had a transient gap.

Proposed Behavior

For PW/WMO alerts:

• If an alert was in the previous fetch but missing from the current fetch, mark it as "expired/cancelled"
• Use the alert's expires timestamp as a signal: if current time < expires and alert disappeared, it may be a transient gap (don't immediately cancel). If current time >= expires, it genuinely expired.
• Consider a grace period (e.g., 2 consecutive missing fetches) before treating a disappeared alert as cancelled, to handle transient API gaps
• Fire a "cancelled" notification when an alert is confirmed gone

References

• Alert lifecycle diff: src/accessiweather/weather_client_base.py (diff_alerts)
• NWS cancel references: _fetch_nws_cancel_references()
• PW alert parsing: src/accessiweather/pirate_weather_client.py (_parse_alerts)