feat(portal): preload site fonts from sd _hashes

[BatLeDev]

Preload a portal's custom body/heading fonts so the browser fetches them earlier, shortening the serial HTML→_theme.css→woff2 chain.

Why: custom site fonts were only discovered after _theme.css loaded, delaying first paint with the correct typeface.

What changed:

• fonts/service.ts: extract a shared getFont helper; add getFontFamilyAssets (returns the @font-face CSS + a preload URL from a single DB/file read) and pickPreloadUrl (normal-style, latin-subset regular/variable face). getFontFamilyCss unchanged in behavior.
• portals/service.ts: getThemeFontFields resolves body/heading font CSS plus a single preloadLinks list. Each font link is built with as: 'font', crossorigin: true and the MIME type derived from the URL — the { href, as, type, crossorigin } objects carry everything the consumer needs.
• api/src/app.ts + ui/index.html: the portals-manager UI (a Vue SPA served by lib's serve-spa) opts into preloads via a {PRELOAD_LINKS} placeholder and lets serve-spa fetch _hashes itself (privateDirectoryUrl option) — removing the duplicated getSiteHashes (utils/site.ts, which also had THEME_CSS_HASH/PUBLIC_SITE_INFO_HASH swapped).
• portal/server/plugins/sd-resources.ts: read the optional preloadLinks field from _hashes and emit one HTML-escaped <link rel="preload"> per entry (driven by as / type / crossorigin) before the theme stylesheet.

Regression risks:

• Depends on the matching simple-directory + lib branches (which make _hashes emit preloadLinks). Backward-compatible in isolation: hashes.preloadLinks ?? [] → no preloads, nothing breaks — mind the deploy ordering.
• The theme object now carries an extra preloadLinks key sent to SD, which relays it as-is.
• getFontFamilyCss now delegates to the new getFont helper; behavior unchanged but the font router shares this path.
• The preload href must round-trip through _hashes byte-identical to the src: url(...) in the generated @font-face for the browser to dedupe.