fix(instatus): anchor the year heuristic on the entry's earliest timestamp

[anthonybaldwin]

Problem

The presence ticker reported 6 active incidents while only 5 were real. The extra one was Kagi's Database maintenance for Kagi Search (cmrbr5ynx05vc0kp9eoawdsbu), which completed on 2026-07-19 but has been counted open ever since — it also left a stale pinned card in the kagi channel.

Root cause

The Instatus Atom feed omits the year from each update's <small> timestamp. parseUpdateTimestamp reconstructed it from <published> and rolled forward a year for anything landing >24h before it.

That assumes <published> is a lower bound on the entry's updates. True for incidents; false for scheduled maintenance, where <published> is the scheduled start and the announcement is posted days earlier (<updated> carries the announcement time):

<published>2026-07-19T06:00:00Z</published>   <- scheduled start
<updated>  2026-07-08T07:24:48Z</updated>     <- announcement
  Jul  8, 07:24:48  Identified   "We plan to perform a minor upgrade..."
  Jul 19, 06:00:01  Identified   "Maintenance is now in progress."
  Jul 19, 06:07:55  Completed    "Maintenance has completed successfully."

Jul 8 is 11 days before <published>, so it was dated 2027-07-08. parseUpdateBlocks sorts chronologically, so the announcement sorted last, and the entry's derived status came from it (in_progress) instead of the final Completed. resolved_at stayed null → permanently open.

Document order can't be used as a fallback signal — real feeds emit update blocks out of order (kagi and perplexity both emit Resolved before Investigating on some entries).

Fix

Anchor the year heuristic on the earlier of <published> and <updated> — a genuine lower bound for both entry types.

Verification

• New regression test reproduces the stuck maintenance (fails before, passes after); full suite 29/29.
• Replayed against the live kagi (43 entries) and perplexity (25 entries) feeds, diffing old vs new parser output: exactly one update timestamp changes (...:2027-07-08 → ...:2026-07-08) and kagi's false open incident drops to zero. No other timestamp or id shifts.

Deploy note

The update id embeds its timestamp, so the one changed id counts as unseen and would re-post that resolved maintenance once. Handled by a one-time state.json repair alongside the rollout.