Read validate.py's Markdown and the README Link Definitions Through markdown-it-py #3426

What Remains

The change that deleted spec/carried_text.py moves the region reading of the audit, scripts/carry.py, scripts/build_dist.py, and scripts/canonical_review.py onto spec/fidelity_text.py, which reads headings and code blocks with markdown-it-py. Two hand-written Markdown readers are still outside it.

spec/validate.py

• markdown_targets() toggles a fence on any line opening with three backticks or tildes, then finds link targets with MARKDOWN_INLINE_LINK and MARKDOWN_REFERENCE_LINK.
• markdown_section() finds a section with an exact-case ^## <name> regex.
• The section-declaration check in main() collects headings with ^## (.+?)\s*$, so a ## shown inside a fence counts as a heading there.

Folding these in is not a call-site swap, for two reasons.

• spec/resolve_description.py imports validate, and repo-config/configure.sh runs it under whatever Python 3.7+ it probes. A top-level import markdown_it in validate.py breaks that path, so the import has to stay on the path main() reaches, or configure.sh has to run the resolver through uv.
• Reading link targets from tokens changes what the carried-link check sees. A target inside a code span, an autolink, and a reference definition inside an HTML block each read differently, so the change needs its own before and after comparison.

references() against _LINK_DEF in spec/audit_markdown.py

The README tagline check resolves [text][ref] through markdown-it's reference table, references(). The link-naming, shield, and 3rd Party Tools checks read definitions with the _LINK_DEF regex over the unfenced text instead. The two disagree on a constructed README such as this one:

[docs]: https://example.com/a
[docs]: https://example.com/b
[Docs]: https://example.com/c

markdown-it reads one definition, the first, and matches its label without regard to case. The regex reads three. The dict the shield and tools checks build from it keeps b for docs and c for Docs, so a ![x][Docs] resolves to a different target there than GitHub renders. markdown-it-py 4 records each definition's line span in env["references"][label]["map"], so the definitions, their order, and their positions can all come from the parser. The raw label and destination still come from the source line at that span, since the parser stores them normalized.

Done Means

• spec/validate.py and the _LINK_DEF consumers read through spec/fidelity_text.py or markdown-it-py tokens.
• python3 callers of anything that gains a third-party import move to uv run --no-project --script, or the import stays lazy where a plain-python3 importer remains.
• The full audit sweep and spec/validate.py's output match before and after, or each difference is explained.