The audit caught a real bug: `resources.css` declared
`font-family: 'IBM Plex Mono'` and `font-family: 'Libre Baskerville'`
as literal font names. `next/font/google` does not register the loaded
webfonts under those names — it generates hashed family names and
exposes them via `--font-ibm-plex-mono` and `--font-libre-baskerville`
CSS variables on the same element that gets the `*-module__*__variable`
class.
The shipped CSS therefore never used the downloaded webfonts; visitors
without the fonts installed locally saw the generic monospace / Georgia
fallback chain instead of the intended typography.
Switched all four font-family declarations to reference the variables
first, then the literal name, then a generic family:
font-family: var(--font-ibm-plex-mono), 'IBM Plex Mono', ui-monospace, ...
font-family: var(--font-libre-baskerville), 'Libre Baskerville', Georgia, serif
Also fixed the Wordmark SVG which had a hardcoded `fontFamily` SVG
attribute (overrides CSS); replaced with an inline `style` referencing
the same CSS variable.
Verified the CSS bundle now contains var(--font-ibm-plex-mono) and
var(--font-libre-baskerville) at the relevant rules.