feat(code-block): user-configurable Shiki theme (light/dark independent)

[SsparKluo]

Problem

Code block syntax highlighting is hardcoded to GitHub Dark/Light Default regardless of the active UI theme. getShikiTheme(isDark) in src/lib/shikiTheme.ts ignores the preset entirely, so every Shiki-rendered surface — fenced markdown code, bash tool commands, diffs, file previews — looks like GitHub even when the user has picked a different UI theme.

Solution

Make the Shiki theme user-configurable in Appearance settings, with light and dark picked independently (each switches with the resolved color mode). Defaults preserve current behavior (GitHub Light/Dark Default), so existing users see no change.

Highlights

• All 65 Shiki bundled themes available. Uses bundledThemesInfo from shiki/themes directly as the canonical catalog — no maintenance burden when Shiki adds new themes.
• Per-theme lazy loading. Worker uses each entry's static import('@shikijs/themes/<id>') literal, so Vite generates one ~14–46 KB chunk per theme and only fetches on first use. Init preloads just the user's current 2 choices; total init cost unchanged for default users.
• Single point of resolution. All Shiki surfaces (markdown fenced code, BashRenderer, DiffViewer, CodeMirrorReadonly, CodeBlock, CodePreview, AttachmentDetailModal) go through useSyntaxHighlight, so changing the setting updates every code-bearing surface automatically.
• Minimal re-render footprint. New useCodeBlockThemes() hook subscribes to a derived string key, so code blocks only re-render when the theme IDs actually change — not on every appearance tweak.

Implementation

• themeStore: new codeBlockThemeLight / codeBlockThemeDark fields with localStorage persistence + export/import backup.
• src/lib/codeBlockThemes.ts: catalog wrapping bundledThemesInfo, with normalizeCodeBlockTheme fallback.
• src/workers/shikiWorker.ts: theme map from bundledThemesInfo, new ensureTheme(instance, themeId) for lazy loading.
• src/lib/shikiWorkerClient.ts: init reads localStorage to preload user's choices (was hardcoded GitHub).
• src/lib/shikiTheme.ts: new getShikiTheme(isDark, light, dark) signature, falls back to GitHub on invalid id.
• src/hooks/useSyntaxHighlight.ts: 3 call sites pass user's configured themes; new useCodeBlockThemes() subscription.
• src/features/settings/components/CodeBlockThemeSettings.tsx: new Appearance section with two grouped <select> dropdowns (themes grouped by light/dark, but cross-picking allowed) + live Shiki-rendered preview.

Backward compatibility

• Default themes: github-light-default / github-dark-default → identical to current behavior
• No migration needed — missing localStorage keys fall back to defaults
• Backup import normalizes unknown/missing theme IDs to defaults

Verification

• tsc --noEmit: clean
• vitest: 525/525 passing (added 2 cases for getShikiTheme)
• npm run build: success — per-theme chunks emitted as separate files (e.g. one-dark-pro-*.js 33KB, dracula-*.js 21KB, github-dark-default-*.js 14KB)

[lehhair]

我之前改了用户信息，导致后面的 commit hash 都变了，所以你当前的 PR 分支需要基于新的历史重新整理一下。麻烦先备份原分支，然后从最新的 main（如果 PR 目标是 dev 就用 dev）新建分支，把本次 PR 的提交按顺序 cherry-pick 过去，最后强推回原来的 PR 分支：

git fetch upstream --prune --force
git switch <PR分支名>
git branch backup/<PR分支名>-before-rewrite

git switch -c <PR分支名>-rebuilt upstream/main
git cherry-pick <本次PR的commit1> <commit2> ...

git branch -f <PR分支名> HEAD
git switch <PR分支名>
git push --force-with-lease origin <PR分支名>

强推原分支后，现有 PR 会自动更新，不需要关闭或重新提交。不要直接执行普通 git pull 或把新旧历史合并到一起，否则会把旧历史重新带回来。

感谢，麻烦了，之前用的是别的设备写的代码，导致用户信息填错了

[SsparKluo]

已基于最新的 upstream/main (00a7ccc4) 重建分支并 force-push，PR 已自动更新。

操作记录：

• 备份：backup/feat-code-block-theme-settings-before-rewrite
• 从 upstream/main 新建临时分支，cherry-pick 了原 PR 的两个 commit（feat + 清理 TODO.md）
• --force-with-lease 推回 feat/code-block-theme-settings

GitHub 这边显示 mergeable: MERGEABLE，typecheck / 525 tests / build 都过。感谢指出。