docs: vendor the VitePress config; serve static assets from public/

[lkdvos]

Split out of #449 so it can be reviewed on its own; independent of the documentation content.

MarkdownVitepress does not expose themeConfig.search or markdown.config, so docs/src/.vitepress/config.mts is vendored from the DocumenterVitepress template with the MPSKit hooks added on top. Since a vendored copy silently rots, make.jl checksums the upstream template and warns when it changes, naming the versions our copy is a faithful superset of.

VitePress serves src/public/ verbatim at the site root, which is what the logo and favicon need; src/assets/ is for files Documenter processes. Moved accordingly.

What this does about #477 and #478

Two independent things were going wrong.

Structure was invisible in docstrings. Documenter rewrites markdown headings inside a docstring into bold-only paragraphs (recursive_heading_to_bold!), so there is no <h*> left to style. A markdown-it rule in config.mts tags exactly those paragraphs and the CSS gives them a heading-like treatment — spacing, size, and a light rule beneath — so the structure reads even where bold does not.

Bold did not render as bold on Linux. VitePress' reset sets font-synthesis: style, permitting a synthesised oblique but not a synthesised weight. That is fine wherever the resolved font has a real bold face, as -apple-system and Segoe UI do. But the DocumenterVitepress stack names three families it never loads (Barlow, Inter var experimental, Inter var), and on Linux fontconfig satisfies those and the platform names after them with a single regular face — every one of the 15 names in that stack resolves to DejaVuSans.ttf "Book" here. So font-weight: 700 computes correctly and still paints at regular weight.

This PR allows weight synthesis and does not touch the font stack, so nothing changes on platforms that already resolve a real bold face. It is deliberately the smallest change that fixes the reported symptom, and it is what I intend to propose upstream — at which point this rule can be deleted.

There is a deeper issue behind it, kept separate on purpose: VitePress self-hosts Inter with a real 100–900 weight axis, but the DocumenterVitepress stack names the family names VitePress used before vuejs/vitepress#3694 renamed the face to plain Inter, and omits plain Inter. Every DocumenterVitepress site therefore downloads a font it never uses. Naming it would give real bold faces rather than synthesised ones, but would also change body text on every platform — a look-and-feel decision for upstream, not something to fold into a bug fix.

Unverified

The VitePress build cannot run on my machine (rollup's native module needs a newer glibc), so I have not seen this rendered. The mechanism checks out at every layer I could inspect, but confirmation that bold now reads as bold on Linux needs CI or a preview deploy — ideally from @leburgel, who reported #477 on Ubuntu/Mint.

🤖 Generated with Claude Code

[github-actions]

After the build completes, the updated documentation will be available here

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[leburgel]

Docstring headers look bold to me now, and I can target library entries with the search like I wanted!