chore: assert that a symbol named in the docs exists

[DavidCozens]

docs/ names library symbols in prose and in fenced examples, and nothing
asserts that any of them exist. Three instances of the same defect were found by
hand on 2026-08-10, two of them by review rather than by a gate:

• docs/platforms/windows/setup.md named SolidSyslogWindowsHostname and
  SolidSyslogWindowsProcessId; the symbols were _Get-suffixed.
• docs/platforms/posix/setup.md carried the identical pair for Posix.
• docs/platforms/freertos/setup.md named the component where the function was
  meant.

All three predated the branch that found them, all three sat on pages that build
green under mkdocs build --strict, and all three would give an integrator who
copied the page an undefined-symbol error.

scripts/check_platform_docs.py already parses every platform header and every
platform page, and already runs in the docs-build lane, so the assertion has a
home: a SolidSyslog… token in a page resolves to a symbol declared in a public
header, or to a file that exists, or it fails. The awkward part is the exception
list rather than the check — docs/NAMING.md names old spellings deliberately as
counter-examples, and prose sometimes names a class rather than a function.

Deliberately not for 0.1.0: David's call, 2026-08-10 — the checking is not
needed for the beta, and the remaining platform triages are the higher-value use
of the time. Raised so the finding survives.

Related: nothing compiles the fenced C examples in docs/ either, and two
defects have been found in examples by reading alone. That check is larger; this
one is strictly cheaper and catches a different class.

[DavidCozens]

Milestoned to 0.2.0 — the deferral reason has expired, and the work got cheaper

Reviewed against the tree during the pre-0.1.0 issue audit.

The three defects are fixed. No setup.md names SolidSyslogWindowsHostname,
SolidSyslogPosixHostname or either ProcessId sibling any more. The gate is
what never landed.

The root cause is still standing, and the tree demonstrates it.
SolidSyslogWindowsHostname is a real token in this repository — it is the
filename Platform/Windows/Interface/SolidSyslogWindowsHostname.h. The function
is SolidSyslogWindows_GetHostname. A page that names the file where it means
the function therefore reads plausibly, builds green under
mkdocs build --strict, and gives an integrator who copies it an undefined
symbol. This is exactly why the proposed rule already admits both forms: a token
resolves to a declared symbol or to a file that exists, or it fails.

The stated reason for deferring no longer applies. It was David's call on
2026-08-10 that the checking was not needed for the beta and that the remaining
platform triages were the better use of the time. The beta is being cut and the
triages are done, so neither half holds.

It is now the second consumer of a script rather than a new gate. A chore is
going out that asserts a repo-relative path quoted in a .md, .yaml or CMake
file resolves, and it is deliberately structured to leave a seam here — same
extraction pass, same exception mechanism, same wiring into docs-build. Land
that first; this becomes the symbol arm of it.

The note below about compiling the fenced C examples stands as written: a larger
and different check, not this one.

[DavidCozens]

#773 has landed. scripts/check_references.py is in the docs-build lane asserting that repo-relative paths quoted in .md, .yaml and CMake files resolve, and it carries the seam for this issue explicitly — the script names #740 as the symbol arm of the same extraction pass. This is now an extension of a working gate rather than a new one.