no-duplicate-list-update-time - Restore feature on new issue and PR lists - #10359

Created by Claude, will be reviewed by @fregante first.

Restores the feature on the new issue and PR lists: it only observed the legacy .js-navigation-item[id^="issue_"] rows, which no longer exist. The new rows are li[class*="listItem"] and the times live in [data-testid="timestamp-container"], with the update time wrapped in its own <span> ("· Updated …") that is removed when it's within 10 seconds of the state change time. The legacy selector is kept for the lists that still use it.

Also made the feature safe when the datetime attribute is missing, so it can never hide a time by mistake, and when the update time isn't shown at all.

Part of #10065

Test URLs

• https://github.com/sindresorhus/refined-github/pulls?q=sort%3Aupdated-asc+is%3Aclosed
• https://github.com/sindresorhus/refined-github/issues?q=is%3Aissue+sort%3Aupdated-desc+is%3Aclosed+comments%3A0
• https://github.com/issues?q=is%3Aissue+is%3Aopen+author%3Afregante+archived%3Afalse+sort%3Aupdated-desc
• https://github.com/refined-github/refined-github/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc (added)

Checked

• Logged out, on the last URL: open PRs show "opened … · Updated …" in each row, in the structure the selector expects. Closed PRs sorted by update time don't show an update time at all.

Not checked

• Whether the datetime attribute is set on the <relative-time> elements once the page is hydrated: the server-rendered markup doesn't have it, so this needs a hydrated, logged-in page. If it's missing there, the feature does nothing (it never hides anything without it), and the time would need to be read from the element's date property instead.
• That a PR with its update time within 10 seconds of opening actually loses the "Updated" part.