线性化提交整理

目标：把 worktree 或功能分支的提交历史整理成一串线性、颗粒度合适、信息规范的提交。整理本身就是完整交付；如用户同时要求合并，再以 fast-forward 方式并入目标分支（未指定时为主干）。

适用形态：

• 整理并合并：整理分支历史后并入目标分支——目标分支由用户指定，未指定时默认为主干
• 纯整理：只重写分支历史，不合并——包括整理某个 hash 之后的提交、整理已推送的分支（整理后需 force-push）

这类工作的价值在于：主干历史是团队理解演进过程、二分定位问题、异常时按提交粒度回退的事实源。颗粒度合适的直接含义是——任意一条提交出问题时，单独 revert 它就能安全回退，不牵连无关改动。整理过的历史应当读起来像一份精心撰写的变更叙述，而不是开发过程的实况录像。所以整理时的每一个判断——哪些提交合并、合并到哪、信息怎么写——都要站在「半年后读这段历史或紧急回退的人」的立场上做。

四条不可妥协的原则贯穿全流程：

1. 不丢作者：合并提交必须保留原始开发者的归属（见「保留作者归属」），整理人是编辑不是作者。
2. 不跳检查：任何提交都不允许 --no-verify 绕过项目 git hooks；hook 失败就修原因，不绕过。
3. 不动代码：整理只改历史结构，最终 tree 必须与整理前逐字节一致（见「验证」）。
4. 执行不外包：盘点、分组判断、rebase / 重写、tree 验证必须全部由当前会话亲自执行，不得委派子代理。历史整理的正确性依赖对全部上下文（每个 diff、hook 行为、冲突语义、归属安排）的连续把握，委派产生的上下文断层会直接导致功能偏移或归属丢失；子代理的「完成」回报也无法替代亲自跑出的 git diff 空结果。

前置检查