v2.2.0

v2.2.0

启动页补上快捷键（F1 与 S，顺手修掉 [A] 那个假标签）；条目管理页中间那段空缺填掉、动作条与提示行钉在列表底下；「预设方案」点名字改成打开列表；拖动分隔条改成即时重排；[+] 新建条目 失色修好。

#	内容
启动页有了快捷键	用户：「启动页连个快捷键都没有，[A] 外观 / 主题 还是假的」。三件事叠在一起：① 侧栏六行里只有五格写了记号，启动那行是 启动 (Startup)，一个键都没绑；② [A] 那行写着记号却从没绑过字母（只有 F2 能用）⇒ 画着能按、按了没反应；③ M/A/K/B/W 这几个字母只在启动页认 ⇒ 进了别的页就按不回来，只能一路 ←/→ 或 Esc 退出去重进。现在 g_settings_nav_letters[] 把六个字母在所有设置页统一认（F1..F5 照旧，任何一页都能按），记号位与侧栏文字共用 sb_label[] 一份表 ⇒「画在一处、点在另一处」这一类从根上没有；字母被当前页自己用掉时让路（条目管理页的 S 仍是「设为启动默认」、A 仍是添加，行为页的 A/B/K/W/M 仍是单键开关，那两页换页请用 F1..F5），判定用 !is_ctrl && !is_alt，不动命中判定的输入时序。
条目管理页那 4 行空缺	用户：「条目管理中间有一段很大的空缺」。根因是这一页的行号在渲染、命中、滚动条、页脚读数四处各抄了一份常数（表头 / 首条 / 动作条 / 提示行都是写死的数字），首条从第 10 行提到第 6 行之后没人再对齐全套 ⇒ 说明行与表头之间空 4 行。现在 SETTINGS_MANAGE_HEAD=5 / ITEM0=HEAD+1 / BAR(n)=ITEM0+n+1 / HINT=BAR+1 / TAIL=2 一份宏，四处都从它推（settings_manage_row_view、settings_manage_natural_at、settings_page_band_raw、settings_page_mark），末条行号由条目数现算（settings_manage_last()），不再拿 26 硬夹。
动作条与提示行钉底	省行数是对的，但 [+] 新建条目 / [P] 预设库 / [设为默认] 与提示行原本算在可滚内容里 ⇒ 条目一多它们就滚不出屏（要点新建得先把列表滚到底，而滚到底又被「聚焦行必须可见」的夹取挡在中间）。现在这两行钉在可见带底下（SETTINGS_MANAGE_TAIL）：列表短的时刻在末条下面一行，列表长的时刻在倒数第二、最后一行，一行的条目地方都不占。顺带把页脚那截 (3-9/12) 的行窗读数收进同一支 settings_page_vis() —— 以前只有滚动条那边减了 2 行、读数没减，报出来的带比画面宽两行（照着它去点第 10、11 行，点到的是按钮和提示，不是条目）。
「预设方案」点名字	用户：「点 GitHub Light 也可以打开预览」。以前名字那一段是「直接换到下一个方案」，而 ‹ › 两格才是上一个 / 下一个 —— 结果想挑个方案只能一遍遍点、看不见全集。现在点名字 = 打开方案列表浮层并把光标停在当前那条上（所见即所朝），Enter 应用；只有 ‹ › 两格仍算上一个 / 下一个。两格的列位由 settings_pane_scheme_arrow_col() 给（main_left+11 / +28），渲染与命中同出一处，漂了就红。
拖动分隔条即时重排	用户：「拖动分隔条时改成即时修改渲染」。v2.1 早期为了「一次拖动把 scrollback 从 93 行吃成 0」把两侧一起冻结到松手才 resize，代价是拖动途中画面纹丝不动。现在改成拖动中就重排，但每 90ms 最多提交一次（SPLIT_DRAG_LIVE_MS），松手时再无条件补最后一次 ⇒ 快速一划不会连着发几十次 ResizePseudoConsole / TIOCSWINSZ，慢速拖动能实时看到结果；历史不被吃这条仍由 hist_lines 与 scroll_offset 的原式子守。按用户要求不加 ini 开关。实测：12×100 分屏后按住分隔线往左拖 6 格，未松手右窗格 stty size 已经从 50 列变到 57 列，松手后仍是 57（不反弹）；改前的二进制同样三个读数是 50 → 50 → 57。
[+] 新建条目 失色	用户：「没有前景色、背景色、也没有 hover 色」。不是没写样式：动作条那一行的样式段正好落在窗口左边界那一格上，hcut() 的 used > from 条件把「从第 0 列起笔的第一段 SGR」整段丢掉 ⇒ 后面所有文字都拿默认色画（[P] 预设库、[设为默认] 跟着一起失色，hover 换底也看不见）。现在 hcut() 把「起点之前已经生效」的那截样式带到裁切结果里，实测未 hover 是 48;2;033;038;045 底 + 38;2;063;185;080 字，划过去底色换成 63;185;080。两处颜色都是已登记的主题字面量，没有新增用色。
回归判据	tests/verify_pane_palette.py 新增 R20–R24 共 13 条（R20a 四条按键路径、R20b S 不被抢走、R20c 侧栏 [S] + 六名同列、R21 两档终端高度、R22 按钮上色与 hover、R23a/b/c、R24 拖动即时重排），全量 176 条全绿（4 条 SKIP 是 libvterm 相关的老组）。拿去跑 v2.1.9 的二进制（对照用的那份是从 de58160 现编的，与 Release 那版源码同源；tag 上多的 218d2f6 只动了判据没动 C）⇒ 恰好 12 条红：R20a×4、R20c、R21×2、R22、R23b、R24，加上新排版打红的既有两条（J1 文案、Q7 行窗）；R20b / R23a / R23c 在两版都绿 —— 它们是「别改过头」那一侧的护栏（S 仍归本页、箭头列位与命中同源、箭头仍是换方案）。四条被新排版打红的既有判据是逐条量过屏幕才改的，不靠放宽不等号变绿：M3 详情页原先传的 ini=ini3 其实是 E3 用例剩下的「ini 文件内容」串（里面根本没有 [menu] 段 ⇒ 条目数 0），「能不能滚到第 3 个字段」只是碰巧成立，现在自造三条菜单的 fixture 并改判「基线可见标题 + 前三个字段而按钮在带外 / 滚五下标题出屏、按钮进来」；Q3 的「轨道下端」随可见带从第 11 行挪到第 9 行（点第 10、11 行现在点的是按钮与提示）；Q7 改成量「▶[9] 停在可见带末行、它下面紧接的一行就是动作条」；J1 认新文案子串。R24 量的不是画面而是子 pty 的宽度（pane_resize_to 里 TIOCSWINSZ 与本地 screen_resize 同帧 ⇒ 窗格里 stty size 报的列数就是「模型有没有跟上」），拖动途中每一格用一次捕获边界隔开（间隔远大于 90ms 节流）。没装 libvterm-dev 的机器一律打 SKIP 而不是崩：TERMUX_NO_VTERM=1 本机复跑 50 ok / 55 SKIP / 0 FAIL。