[quality] transformMdx.ts:124 closing-tag regex typo [A-ZaZ0-9._-] misses lowercase custom closing tags

## Finding `src/lib/transformMdx.ts:124` has a character-class typo in the regex that entity-escapes unknown/custom closing tags: ```ts .replace( /<\/([A-Za-z][A-ZaZ0-9._-]*[-_][A-Za-z0-9._-]*)\s*\\?>/g, // ^^^^^ — should be [A-Za-z0-9._-] (_m, name) => `&lt;/${name}&gt;` ) ``` The character class `[A-ZaZ0-9._-]` allows the ranges `A–Z`, `a–Z` (an empty range in ECMAScript — `Z` is 0x5A and `a` is 0x61, so this is either a runtime SyntaxError depending on engine, or silently degrades to just `Z` + `a`), plus `0-9`, `.`, `_`, `-`. The compiled behavior in V8 accepts the pattern but the second range effectively adds only the two literal characters `Z` and `a`, which means every lowercase letter b–z after the first character is rejected. Consequence: lowercase hyphenated closing tags like `</my-widget>`, `</custom-element>`, or `</header-bar>` **are not entity-escaped** and get passed through to MDX unchanged. MDX will then try to resolve `my-widget` as a React component, fail, and either throw at build time or render nothing. The sibling *opening*-tag regex two lines above (line 120) is correct: ```ts .replace( /<([A-Za-z][A-Za-z0-9._-]*[-_][A-Za-z0-9._-]*)\s*\\?>/g, // ^^^^^^^ correct ... ) ``` so opening tags of unknown custom elements are escaped as expected, but their closing counterparts leak through unchanged — an asymmetry that will produce mismatched tag pairs in the pre-processed MDX output. The test I added in kubestellar/docs#6592 (`encodes an unknown hyphenated closing tag`) had to feed the regex an all-uppercase tag (`</MY-WIDGET>`) to exercise the callback at all; a lowercase input like `</my-widget>` demonstrates the miss. ## Recommendation Fix line 124 to use the same character class as line 120: ```diff - /<\/([A-Za-z][A-ZaZ0-9._-]*[-_][A-Za-z0-9._-]*)\s*\\?>/g, + /<\/([A-Za-z][A-Za-z0-9._-]*[-_][A-Za-z0-9._-]*)\s*\\?>/g, ``` Add a regression test that feeds a lowercase hyphenated closing tag (`</my-widget>`) and asserts the result contains `&lt;/my-widget&gt;`. That test would fail on `main` today and pass after the one-character fix. Grep any repo docs history for lowercase custom-element closing tags in `.md`/`.mdx` sources to confirm no live pages already rely on the accidental pass-through behavior before flipping the fix. ## Priority - Impact: **medium** — hits any `.mdx` page authored with a lowercase hyphenated closing tag (custom-element convention per the HTML spec). Silent failure mode (mismatched tags in the transformed output) is worse than a loud one. - Effort: **low** — one-character regex fix plus one regression test. --- *Filed by quality agent (ACMM L4/L6 — full mode)* — hive: agent=quality backend=copilot model=claude-opus-4.7