chore(tools): migrate Markdown linting to rumdl

[setchy]

Changes

• Replace markdownlint-cli2 and markdownlint-cli2-formatter-template with pinned rumdl@0.2.78.
• Preserve pnpm markdown-lint and pnpm markdown-lint-fix, using rumdl check . and rumdl check --fix . respectively.
• Translate the existing configuration into .rumdl.toml, with comments explaining all 47 enabled rules and the six previously disabled rules. Additional rumdl rules are not enabled as part of this migration.
• Retain the existing Markdown file selection and exclusions, aligned-table checks, legacy markdownlint-disable comments, and markdownlint defaults for code-block tabs, blockquoted lists, and case-sensitive fragments.
• Keep Prettier as the Markdown formatter. Use standard Markdown mode because rumdl's MkDocs flavor assumes four-space indentation and produces false positives for this repository's two-space indentation.
• Use pnpm markdown-lint --output-format github for built-in GitHub Actions annotations instead of the formatter dependency.
• Store the cache in .cache/rumdl, already covered by .gitignore, and update the local-development documentation.

Local before/after benchmarks

Measured on the same 338 Markdown files during the migration's read-only comparison. Both tools returned zero issues, and their enumerated file sets were identical.

Environment: Apple M4 Pro, macOS 27.0.1, arm64, Node.js 24.21.0, pnpm 11.28.4.

Tool / mode	Command	Median wall time	Relative to before
Before: markdownlint-cli2 0.23.3 (markdownlint 0.41.1)	node_modules/.bin/markdownlint-cli2	942 ms	1.00×
After: rumdl 0.2.78, result cache disabled	node_modules/.bin/rumdl check --no-cache .	225 ms	4.18× faster
After: rumdl 0.2.78, populated result cache	node_modules/.bin/rumdl check .	224 ms	4.20× faster

Methodology: run each command once as an untimed warm-up, then measure five sequential subprocess runs with Python's time.perf_counter() and report the median. Output was captured and every run exited successfully. Timings include CLI launcher/process startup, but exclude installation and pnpm command startup. The filesystem cache was not cleared: "result cache disabled" is not a cold-filesystem benchmark. These are local measurements, not a claim about CI performance.

Raw measured wall times in seconds:

• markdownlint-cli2: 0.879222, 0.870512, 0.942448, 0.956442, 0.958149.
• rumdl, result cache disabled: 0.248351, 0.225197, 0.225420, 0.277993, 0.215380.
• rumdl, populated result cache: 0.198974, 0.205987, 0.224327, 0.389236, 0.635433.

Validation

• Before/after file enumeration: identical 338-file scope, zero issues with both linters.
• pnpm exec rumdl check --no-cache --deny-config-warnings .: passes on all 338 files.
• pnpm markdown-lint, pnpm markdown-lint --output-format github, and pnpm markdown-lint-fix: pass; the fixer makes no additional Markdown changes.
• Targeted pnpm check --all for the changed files: passes. The local runner required putting the working Corepack pnpm shim first on PATH to avoid an unrelated ENOEXEC from another local pnpm shim.
• Ad hoc configuration smoke checks verify heading diagnostics, disabled rules, legacy numeric/named suppressions, table alignment, code-block tabs, case-sensitive anchors, two-space admonitions, mixed list indentation, all 13 exclusion categories, and GitHub annotations with failing exit codes.
• git diff --check: passes. No new unit tests were added and the full repository unit-test suite was not run.

Context

Please select one of the following:

• This closes an existing Issue, Closes: #
• This doesn't close an Issue, but I accept the risk that this PR may be closed if maintainers disagree with its opening or implementation. Because this does not close an Issue, I will add a minimal reproduction repository as part of this PR.

AI assistance disclosure

Did you use AI tools to create any part of this pull request?

Please select one option and, if yes, briefly describe how AI was used (e.g., code, tests, docs) and which tool(s) you used.

• No — I did not use AI for this contribution.
• Yes — minimal assistance (e.g., IDE autocomplete, small code completions, grammar fixes).
• Yes — substantive assistance (AI-generated non‑trivial portions of code, tests, or documentation).
• Yes — other (please describe):

OpenCode using GPT-6.1 Sol (github-copilot/gpt-6.1-sol) authored the configuration, dependency/script/CI changes, documentation, configuration smoke checks, local benchmark comparison, and this PR description under the contributor's direction.

Use of AI in replying to PR comments

Who answers review comments:

• @username will read and reply directly. Name the account.
• An agent will draft replies and @username will read them before they are posted. Name the account.
• An agent will draft replies and reply autonomously. This is heavily discouraged, and we prefer that there are humans in the loop
• Nobody has explicitly committed to replying.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests, but ran on a real repository, or
• Both unit tests + ran on a real repository

The public repository: http://github.com/setchy/renovate/tree/feat/markdown-rumdl

A reproduction is compulsory for PRs that do not close an Issue: link a public repository above that reproduces the bug or shows the new behavior.
If this PR closes an Issue, confirm the fix against the Issue's reproduction.
If you are not adding a reproduction, state your reason here:

This is a development-tooling migration, not a dependency-update bug. The public fork branch above is the runnable repository showing the new behavior. A separate minimal reproduction is not included because it would not exercise Renovate's actual lint configuration, exclusions, and 338-file documentation corpus used for compatibility checks and benchmarks.

PRs without a reproduction or a stated reason will not be reviewed and may be closed.