Recognize a Details or Summary Opener Through One Primitive in pr_review.py #3206

The shape

scripts/pr_review.py recognizes a <details> or <summary> opener in several places, each with its own rule for where the tag name ends:

• DETAILS_OPEN requires HTML whitespace or /?> after <details.
• DETAILS_OPENER requires HTML whitespace and attributes, or > directly.
• SUMMARY requires HTML whitespace and a letter, or > directly.
• FOLD_OPENER requires HTML whitespace, >, or the end of the line after <summary.
• FOLD_STOP allows / as well.
• HEADING's <summary branch requires nothing, so <summaryx> opens a heading line.
• heading_of's two startswith("<summary") checks require nothing either. Only the SUMMARY.search beside them stops a <summaryx> from being read as a summary.

Each fix to one of these has had to be repeated by hand at its siblings. #3204 narrowed four of them from Python's \s to [ \t\n\f\r] in one sweep. The promotion of that change, #3205, then drew a Copilot headline asking for the tag-name boundary HEADING lacks.

No reviewer body carries a <summary-prefixed tag of another name, so the missing boundary is not a live misreading. It is the next instance of a class with no single home.

Expected

One primitive says where a <details> or <summary> opener's tag name ends, and every site above builds on it, so each has the same boundary. A test pins <summaryx> and <summary x> as no opener at every site, and <summary>, <summary\tid="a">, and <summary/> as an opener.

Deferred from the headline of Copilot's round on #3205.