docs(site): add inline code spans to generated Starlight pages

Function doc-headers are authored as plain text -- `config-help`,
`funcsave` and anyone opening the `.fish` file read them as-is -- so they
carry no backticks. The site inherited that and rendered `-a/--all` and
`__fish_config_op_aliases` as ordinary prose.

docs/codespans.py adds the spans at render time, as the last step of
prettify(), so only the site sees them; build_concat() (man page,
config-help) is byte-for-byte unchanged.

Recognised shapes: flags and flag pairs, `$vars`, SCREAMING_SNAKE env
vars, snake_case identifiers, paths and filenames, key chords, command
shadow chains (`ls->eza`), runs of tool names, whole command lines in a
table column of command lines, and known command names -- drawn from the
`_fdc_*` catalog in functions/_fish_deps_catalog.fish, the functions/
listing, and a standard-command list, minus the names that also read as
English.

Fenced blocks, existing code spans, headings, link targets, URLs,
component markup and <FileTree> bodies are passed through untouched, and
every rule bails out rather than guess.

CONTRIBUTING.md

@@ -239,6 +239,13 @@ python3 docs/verify-manual.py
 CI runs the same verification and regenerates the site/man page — a broken
 manual won't get published, but running it locally saves a round trip.
 
+Write doc-headers as plain text — no backticks. `-a/--all`,
+`__fish_config_op_aliases` and `~/.config/fish/config.fish` are typed
+bare, because the header is also read as-is by `config-help` and by
+anyone opening the file. `docs/codespans.py` adds the inline code spans
+the docs site wants when it renders, so the SSOT never carries them; see
+`docs/site/README.md` for which shapes it recognises.
+
 ## Testing
 
 ```fish