fix(adoc): resolve empty-text cross-references corrupting walker context

[SudhanshuMatrix]

Description

This PR fixes a silent false-negative bug where rules carrying scope: heading stop matching section titles in an AsciiDoc file if that file combines explicit block anchors with xref: inline macros (having empty link text).

Fixes #1109

Root Cause

1. Dynamic Target Resolution: During HTML generation, Asciidoctor resolves empty-text cross-references (like xref:id[] or <<id>>) using the target heading's title.
2. Missing Source Text: Since the resolved text is not written in the raw source paragraph containing the reference, Vale's walker fails to locate the exact phrase inside the paragraph block.
3. Word-Masking Fallback: As a fallback, Vale starts masking the individual words ("first", "heading", "lowercase") anywhere it can find them in the remaining document context.
4. Context Corruption: This matches and masks the words inside subsequent headings (e.g., "second heading lowercase" becomes "second @@@@@@@ @@@@@@@@@").
5. Silent Drop: When Vale later processes these headings, they fail to match the corrupted context, leading to location lookup failures and the alert being silently discarded.

Proposed Changes

We intercept the AsciiDoc content inside lintADoc in internal/lint/adoc.go before it is passed to Asciidoctor, and rewrite empty-text references:

• xref:target[] -> xref:target[target]
• <<target>> -> <<target,target>>

This ensures that the text rendered in the HTML tag is the literal target identifier (e.g. #intro or intro), which is present in the raw source code of the paragraph. Vale's walker successfully matches and masks it within the paragraph block, leaving subsequent headings untouched.

How to Test and Verify

1. Run Vale with a heading-scoped rule against this sample AsciiDoc file (repro.adoc):

   = Document
   
   [[intro]]
   == first heading lowercase
   
   This paragraph links to xref:#intro[].
   
   [[middle]]
   == second heading lowercase
   
   This paragraph links to xref:#intro[].
   
   [[final]]
   == third heading lowercase
   
   This paragraph links to xref:#intro[].

[jdkato]

Thanks for the PR and the root-cause writeup. The diagnosis is right: empty AsciiDoc xrefs render to the target heading text, that rendered text is not present in the source paragraph, and Vale’s word-by-word fallback can then mask words in later headings. That is what causes the heading-scoped false negatives.

I don’t think we should fix this by rewriting the AsciiDoc before render. xref:#intro[] and xref:#intro[#intro] are not equivalent from Vale’s point of view: the former renders as the target heading title, while the latter renders as #intro. That means paragraph/link-adjacent rules would lint text that Asciidoctor would not actually render. This fixes the heading bug by changing the document Vale analyzes, which is the wrong layer.

I tested a smaller fix in the walker instead: internal/lint/walk.go (778a44f) should preserve Asciidoctor’s rendered output and avoid the global word-by-word masking fallback for .adoc when rendered text is not present verbatim in the source. That prevents synthetic xref labels from corrupting later headings without changing the prose Vale sees.