An issue reopened after a merged declarer is told it was never closed

Observed

scripts/check-issue-links.py prints this remedy for an issue whose declarer already
merged:

#N declared Closes #10 and is merged, which is the shape of work that landed and
was never closed - either close this issue with the reading that says the work is done,
or state here what it still leaves

That sentence is false for an issue that was closed by that merge and then reopened.
The issue was not "never closed": the merge is what closed it, and the reopen is the
record that the landing did not finish the work. The remedy then sends a reader to close
an issue that somebody deliberately reopened.

Where it was observed

Issue #2358's own timeline, read 2026-10-27:

The tool already fetches that whole timeline (timeline() in scripts/check-issue-links.py)
and hands it to referencing_prs, which reads only cross-referenced events. The
reopened event is therefore in hand and discarded; the fact is available at no extra
API call.

Expected

When the issue's newest reopened event is later than the newest merged declarer's
merged_at, the merged clause says the merge is what closed the issue and that the
reopen is why it should not be closed on that reading - state instead what the work still
leaves. In every other case the existing sentence stays exactly as it is.

What the fix must satisfy

1. The remedy stops advising a close when a reopen follows the merge, and keeps advising
   it when no reopen follows - both directions pinned by tests.
2. A reopen that happened before the merge leaves the existing sentence alone: it
   says nothing about that merge.
3. Only declared merges are compared against: a merged PR that merely mentioned the
   issue never closed it, so a reopen after it is not evidence about it.
4. An unreadable timestamp never becomes a silent "reopened" or a silent "not reopened"
   by accident of comparison - the instants are normalised before they are compared.