Keep the space before an inline element that opens a source line

What does this MR do and why?

I want a word and the link on the next source line to stay two words, because Astro 7's default whitespace compression builds the newline <a> as the<a>, and the page reads "thelink". Both site configs now set compressHTML: true, and npm run build ends with check:spacing, which fails the build if a word touches an inline element. The docs starter and the reference site both carry the change, so every consumer takes it at its next repin.

References

• A downstream site found the defect, fixed it with compressHTML: false and a build check of its own: egress!99. It counted 39 joins on 18 pages.
• Astro's compressHTML option: true removes whitespace losslessly, false keeps everything, and 'jsx' is the v7 default.

Standards affected

None.

Exemption implications

None.

Test plan

• just guard, just validate, just check, just build and just agent pass.
• Joins before: 21 in the docs starter, 134 in the reference site. After: 0 in both.
• Option chosen by measurement. true and false both clear every join. HTML size against the default: true +1.8% (139,258 to 141,794 bytes) in the starter and +1.7% (1,496,763 to 1,521,617) in the reference site; false +10.6% and +18.6%.
• true keeps a source newline between a word and a link, code span, strong, em and a table cell link, and leaves pre content unchanged.
• The check fails the build: the starter built with compressHTML: "jsx" exits 1 with 21 glued.
• No false positives: the check reports 0 glued on both sites after the change.
• Not checked: a word glued to the element before it (</a>word). The reference site has 172 such pairs: 171 are heading permalink anchors the markdown renderer emits and one is <code>COPY</code>s, so the check leaves the closing side alone.
• Not checked: <sup> footnote markers, which sit against the word by design.

An AI tool wrote this change and ran the checks above.