Spellcheck the files `spellcheck.yml` cannot see (non-R-package prose)

[d-morrison]

Split out of #257 / #555, where it was named in the claim comment and the PR body as deliberately out of scope rather than dropped.

Corrected after filing. The original text listed README.md as an example of what spellcheck.yml cannot see. That is wrong: spell_check_package() reads root-level Markdown matching readme, news, changes, or index, so a package's own README.md and NEWS.md are checked. Measured against a fixture at {spelling} 2.3.2 (2026-08-21). The gap this issue is really about is narrower, and stated accurately below.

spellcheck.yml wraps {spelling}'s spell_check_package(), whose population is an R package, and specifically:

• DESCRIPTION's Title and Description fields, and no other field
• every man/*.Rd help page
• vignette sources under vignettes/ (.md/.Rmd/.qmd, plus .Rnw/.Snw), parsed as text rather than rendered
• root-level Markdown named readme/news/changes/index, case-insensitively

That is the right scope for #257, which was about letting repos drop their bespoke check-spelling.yaml.

It still leaves a real gap. Nothing in this repo spellchecks:

• a Quarto site's .qmd pages that are not package vignettes -- the bulk of a qwt/qbt/qmt repo
• top-level Markdown that is not one of those four names: CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, anything under docs/
• DESCRIPTION fields other than Title and Description
• code comments and YAML
• this repo itself, which is not an R package at all, so spellcheck.yml cannot be dogfooded here

crate-ci/typos is the obvious candidate: it is a corrections-list checker rather than a dictionary checker, so its false-positive rate on technical prose is far lower than hunspell's, which is what makes it usable on files with no curated wordlist behind them. It also has an official action, and it is language-agnostic, so one capability would cover Markdown, Quarto, YAML, and code comments together.

Open questions for whoever takes this:

• Is it a second capability (check-typos), or an input on spellcheck.yml? Two tools with two vocabularies and two config formats argues for the former, and it would let this repo dogfood it.
• Diff-scoped or whole-tree? A whole-tree first run over an existing repo reflags years of drift, which is the same adoption problem check-new-line-breaks solves by diff-scoping. typos has no wordlist to grow into, so diff-scoping matters more here than it does for spellcheck.
• Does it belong in the lint-* family's naming, or the check-* family's?

Not urgent: nothing regresses while this is open, and #555 shipping does not make the gap worse.