Stop a Blockquoted details Opener's Scan at Its Own Line's End #2416

scripts/pr_review.py's DETAILS_TAG opener alternative, <details(?:[ \t\n\f\r][^<>]*|/)?>, lets an unclosed opener's attribute scan cross line breaks. Behind a blockquote marker, that scan ends on the next line's own > marker rather than at a bracket closing the tag.

Repro, constructed. > <details x\n> ### H (1)\n> </details> reads ['<details x\n>', '</details>']. The opener ends inside the second line's container marker, so the heading on that line starts inside the region the opener begins rather than reading where CommonMark renders it.

This is the opener-side counterpart of the close-tail defect the #2384 branch (#2415) fixes for closes, where a close led by a blockquote marker no longer carries its tail onto the next line. It predates that branch (the [^<>]* bound landed in #2400), and that branch leaves it untouched.

Done looks like. An opener behind a blockquote marker does not take a following line's marker as its bracket, with a test built from the constructed body above, and the linear-time bound #2400 added still holding.

Found by a local-strict-review pass on #2415 and filed as a pre-existing finding, so it blocks nothing.