Markdown configuration migration to new markdown processor API

[patrickpiedad]

…

What

Migrated markdown configuration to Astro new markdown processor API to remove deprecation warnings during development

Why

The previous remarkPlugins configuration is deprecated and will be removed in a future Astro release. This updates the project to the recommended configuration.

Checklist

• npm run check passes (0 errors)
• npm run build succeeds
• Verified in both light and dark mode (visual changes only)
• New config options are documented in src/consts.ts comments and the README
• New features that add client-side weight are opt-in (off by default)

[kpab]

Thanks for the PR! I verified the migration and it checks out nicely:

• The config change matches exactly what Astro's deprecation warning recommends (processor: unified({...}) from @astrojs/markdown-remark).
• I rebuilt the branch locally: npm ci + npm run build pass, the deprecation warning is gone, reading time still renders on both .md and .mdx pages, and the dual-theme Shiki output (--shiki-light/--shiki-dark) is intact.
• The 0.1.0 → 0.2.0 version sync in package-lock.json is welcome — the v0.2.0 release bumped package.json only, so main's lockfile was stale. Thanks for catching that incidentally.

Two small requests before merging:

1. Please add @astrojs/markdown-remark to dependencies (npm install @astrojs/markdown-remark). The config now imports it directly, but it's only present transitively: in the updated lockfile it's an optional peer dep of astro (7.2.2) plus a regular dep of @astrojs/mdx (7.2.0). That works today, but it relies on @astrojs/mdx keeping that dependency — a future mdx release aligned with Sätteri could drop it and break the config import. Astro's own error message for the missing-package case also recommends installing it explicitly.

2. Minor: the lockfile also picks up unrelated bumps (astro 7.0.3 → 7.1.6, language-server/volar dev tooling) and the shikiConfig.themes reformat is unrelated style churn. Neither is blocking — the astro bump is within the semver range and the build passes — just noting it for the record. If you run the install for point 1 anyway, no need to untangle the rest.

Happy to merge once point 1 is in.