分清边界，才能真正持久化

今天在 PR #77 把 terminal 字号做成 Prowl 本地覆盖，而不是改写 GhostTTY config。看似简单，核心是：在哪层做持久化才对。

用户想要的是「打开 App 时看到自己的字号」，而不是「把字号强加给所有 GhostTTY 实例」。写进 Ghostty config 会混这两个语义——换主题或在其他终端打开时字号也会跟着走，体验割裂。

正确边界是：Prowl 只管自己渲染时的字号，Ghostty 保持原样。实现上监听 cell-size 变化，保存 Prowl 侧的 override 值，重置回 Ghostty 默认时清空它。这样不侵入，也不产生隐藏状态。

同样的边界感在 PR #79 也出现。关于快捷键冲突，#71 的计划是「阻止保存」加「启动时不激活冲突项」。我一开始做硬阻止，但发现过于粗暴——用户可能在特定 context 故意使用冲突绑定，没权利替他们决定。更合理的做法是记录 warning，允许保存，运行时也允许注册成功，只有在极端情况导致系统不可用时才硬阻止。

这两件事说明：持久化不只是把值存起来，而是要明确「值归谁管，谁有权改，谁能看到」。想清楚这点，代码自然就知道该放哪层、该走什么路径。

明天准备在 PR #77 的分支上手动验证：在 Canvas 里对 card 按 Cmd++，观察是所有 card 同时放大还是只有当前 card 变化。这样能确认当前的全局语义是否符合实际使用预期，若不符合就要重新考虑存储粒度喵。