fix(incidents): a membership row outliving its incident must not gate the next one

[passcod]

🤖 A server can sit red with no incident open and nothing paging, permanently.

is_issue_in_open_incident counted incident_issues rows by left_at IS NULL alone, never consulting the incident's closed_at. Closing an incident doesn't stamp left_at on the members that never left — a sub-failure contributor is held attached for context, and the close paths only touch the incidents row — so those rows outlive their incident and the count read them as live membership.

An issue that already looks attached never opens an incident. Its next effective failure arrives with was_in = true and should_leave = false, so it misses both the join arm and the leave arm and lands in the catch-all, whose only action is un-lingering incidents with closed_at IS NULL — which excludes the closed one. Zero rows updated, nothing opens. No later event can clear the stale row, so it never recovers on its own; reconcile_open_incidents calls the same helper and repairs nothing.

The leave arm selected its membership row the same way, so it comes along. An issue can hold a stranded row and a live row at the same time, and stamping the stranded one weighs remaining_open against a long-closed incident, abandoning the open one with no live members and no Slack resolve.

Impact

At the time of diagnosis prod had 207 stranded issues across 51 servers and 107 closed incidents, accruing continuously since early June. One server had a disk_free check effectively failing for seven weeks — monitored, grouped, never paged.

This is the read-side fix, deployable on its own: it makes every stranded row inert immediately, since membership is re-read on each evaluation. Stamping left_at when an incident closes, and backfilling the existing rows, follow separately.