integration: clear cached Markdown when the options change

[ewels]

Fixes #13.

Cause

• Cached Markdown, not missing options
  • Astro's content layer renders .md pages once and stores the HTML, stylesheet link included, in .astro/data-store.json at the project root (not node_modules/.astro, which is why clearing that did nothing).
  • Astro clears that store only when its digest of the Astro config changes. The digest skips integrations and functions, so a change to the codeblocks() options never reached it.
  • .md pages kept linking the stylesheet of the old options, which the dev server no longer serves. .mdx pages are not stored this way, so they were fine.

Fix

• Options digest on the Markdown processor
  • The integration writes a short hash of the resolved options to markdown.processor.options.starlightCodeblocks. Astro's digest covers that object, so any option change clears the store.
  • Sätteri and unified() read only the keys they know, so the extra key has no other effect.
  • It is in the shared integration hook, so the Starlight and the plain Astro entry points both get it.
  • A test in test/astro.test.ts checks that the same options give the same digest and that different options give a different one.

Verification

• Reproduced on a copy of the nf-metro website
  • With 1.0.1, a full dev server restart after a change to footnotes still served .md pages that linked the old ec.*.css (404).
  • With this branch, .md and .mdx pages link the same served stylesheet after each change.
• pnpm lint and pnpm test pass.

Not fixed here

• Config edits while astro dev runs
  • Astro restarts the server in the same process but keeps the old content layer, with the old Markdown processor, and does not resync. .md pages stay stale until a full restart.
  • This affects any Markdown-related config change, so it needs a fix in Astro. A full restart is now enough, without deleting .astro/.

🤖 Generated with Claude Code