feat(docs): enhance Scalar renderer with custom script and font sourc…

[Orfeo42]

Closes: #1103

Summary

• Bump the pinned Scalar renderer from @scalar/api-reference@1.44.20 to 1.66.1 with a fresh SRI hash, and add Config.DocsScalar (ScalarDocsConfig with ScriptURL, ScriptIntegrity, FontSrc) to override the script location and font source without waiting for a huma release. Override values are validated at registration (rejecting ;, ,, quotes, whitespace, <, >) to prevent CSP and HTML injection.
• Switch the Scalar docs page from the declarative data-configuration attribute to the Scalar.createApiReference('#app', {...}) JS API, allowed via a CSP sha256 hash of the static inline script. This makes the full Scalar configuration work through DocsRendererConfig, including multi-document sources; huma injects the default url only when the config declares none of url, sources, or content.
• Tighten the Scalar CSP: drop 'unsafe-eval' from script-src (verified unused by 1.66.1 in-browser) and add font-src for https://fonts.scalar.com (previously blocked by the default-src 'none' fallback, breaking font loading). style-src 'unsafe-inline' remains — Scalar applies inline style attributes, which no nonce or hash can allow; tracked by the existing TODO.
• Escape the page title with html.EscapeString and precompute the CSP header once at registration in registerDocsRoute (api.go).
• Extract the Scalar branch of registerDocsRoute into focused helpers: scalarScriptFor, scalarFontSrc, scalarConfigJSON, scalarCSP, scalarPage.
• Extend TestDocsRenderers with coverage for custom script URL/integrity, font-src override, multi-document config, config-shape validation, CSP/comma injection rejection, and title escaping.

Breaking Changes

• DocsRendererConfig for the Scalar renderer must now marshal to a JSON object; any other JSON shape panics at API creation (previously any JSON value was serialized into data-configuration).
• The Scalar docs HTML no longer contains the <script id="api-reference" data-url=... data-configuration=...> element; anything scraping or post-processing that markup must adapt to the new <div id="app"> + inline Scalar.createApiReference structure.

[wolveix]

Hi @Orfeo42, thanks for your contribution. We specifically want to avoid registering renderer-specific docs variables (e.g. Config.DocsScalar), nor do I think the new Scalar change is necessary (and, as you said, will break many existing implementations). This looks very AI-driven, with very little regard for the maintainability or usability of the library if I'm honest (no offense intended) :(

I've admittedly only skimmed through this code and haven't tested it locally, but could you walk through some of the design decisions please?