fix(preview): inline code in a heading sits on the heading's baseline (#681)

[PathGao]

What this is

Closes #681, reported by @ac-ekm with a side-by-side against GitHub: ## Heading \code` Test` rendered the code span small and floating above the words around it instead of on their baseline.

Measured on that exact heading, in the preview:

	before	after
code font size in a 24px ##	14px	20.4px (0.85em)
code chip's bottom vs the heading text's	8px above	2px below (the chip's own padding)
code font size in body text	14px	14px
chevron position, single and wrapped heading	unchanged	unchanged

Mechanism

Two independent causes, one per stylesheet, which is why the screenshot shows both a size and a position problem.

The float. .foldable-header is display: flex so the fold chevron can sit beside the heading text. That makes every element inside a heading a flex item — an inline <code>, an image, a KaTeX span — and align-items: flex-start pins each one to the top of the line instead of standing it on the text's baseline. The smaller the element, the further it floats. So this was never about code: anything shorter than the heading's line box has been riding high in every heading since folds were added. align-items: baseline is what inline layout would have done, and the chevron is unaffected because its own rule positions it.

The size. The Code Font Size setting is injected as an absolute --code-font-size and applied with !important, which overrides GitHub's code { font-size: 85% }. Absolute px is right for code sitting in prose — a reader picked that number so code is legible next to their body text — and wrong for code sitting in a heading, where it does not scale: 14px inside a 24px ##, 14px inside a 32px #. The 85% rule is restored for headings only.

!important on the new rule because the rule it has to beat is !important too; specificity alone cannot answer that.

Scope

Body text and code blocks keep answering to the setting — the fix is scoped to h1–h6, so nothing a reader set for reading code changes.

The deeper question the flex container raises is left alone: a heading arguably should not be a flex container at all, and the chevron could be positioned absolutely in the gutter the way GitHub places its anchor links. That would also restore true inline wrapping for headings that mix text and elements. It is a bigger change to a surface that fold state, the TOC and the export path all read, and this fix does not need it — measured, a long heading with inline code still wraps to the same height it did before.

Tests

scripts/headingInlineCode.test.ts, three source-shape assertions: the heading rule aligns on baseline and not flex-start, headings size inline code at 0.85em, and the --code-font-size rule is still there for everything else. Both halves are CSS the browser resolves, so nothing that runs code can see them — and the second test is what stops a future edit from "simplifying" the heading rule back into the general one.

Revert either half and the matching test goes red.

Verification

npm audit             0 vulnerabilities
npm run check         805 files, 0 errors, 0 warnings
npm test              934 pass, 0 fail
npm run test:vitest   42 files, 376 pass
cargo test            148 pass

The table above was measured in Chromium against the dev server, with window.__TAURI_INTERNALS__ stubbed and render_markdown returning a fixture — reading getComputedStyle and getBoundingClientRect off the rendered heading, including a long heading that wraps.

Not verified: how it looks on Windows, where the report came from. The rules are platform-independent, and the fix moves the same two numbers everywhere, but nobody has run it there. The exported HTML and printed PDF inherit both stylesheets, so both routes get the same fix without a change of their own — that path was reasoned about, not run.