預覽區垂直定位使用固定 baseline offset，非常規 metrics 字型（手寫體）視覺偏位

[yintzuyuan]

問題（使用者回報第三例）

Hannotate 等 ascender/line gap 特別大的字型在左上預覽區顯示時視覺偏位。

根因

`update_preview`（glyphs_ui.py）的 `baseline_offset = -4` 是為系統字型 metrics 手調的固定值，未考慮實際選中字型的 metrics。

方案

抽純函式 `preview_baseline_offset(...)` 進 hanzi_core.py 做 TDD，由字型實際 metrics（ascender/descender/capHeight）計算垂直置中；UI 層只讀 NSFont metrics 餵入。垂直置中公式屬字體設計領域判斷，由作者定義預期行為。

[yintzuyuan]

實測發現（Swift/NSTextField probe，on-device）

原規劃的 preview_baseline_offset(ascender, descender, box_height) 方案證實無法修好本 issue 回報的 Hannotate 案例。在真實 90×90 NSTextField（與 vanilla.TextBox 同設定）渲染各字、量測實際墨跡中心（目標 45，y-up）：

字型	offset 0 墨跡中心	需要	baseline-offset 可達？
系統「漢」	44.5（已置中）	—	—
Hannotate SC「書」	35.75（低 9.25）	往上 9.25	❌ 不可能
STHeiti「書」	54.5（高 9.5）	往下 9.5	✅

三個實測事實：

1. 正 NSBaselineOffset 完全無效（單行 top-pinned，只有負值 1:1 往下）。
2. Hannotate 需往上 → 用 baseline offset 結構上做不到。
3. (ascender, descender) 無法表達墨跡落點——Hannotate 與 STHeiti 都是 CJK，墨跡中心卻差 18.75pt（差在 ascender 留白）。

真正修法（待實作）

拿掉 top-pinned 的 TextBox 預覽，改自訂繪製（NSView/drawRect 或自訂 cell）依實際墨跡邊界置中，兩方向才都可達。可 TDD 純函式：box_height/2 - (ink_top + ink_bottom)/2（餵入實際墨跡上下緣，非 ascender/descender）。

已做（部分解，PR #30）

移除寫死的 baseline_offset = -4——實測它反把系統字型推低 4pt（40.5），移除後回到 44.5 正中。Hannotate 與短 ascender CJK 仍需上述自訂繪製，本 issue 保持開啟追蹤。