core: 结构重排下的增量 Search 保持文档序 (#27/#164) - #175

背景

#169 封存了行存储并给出精确 rank，但它明确把运行中跨结构重排的增量 Search 留作后续（"开放新无序行为前需另行完整验收"）。本片补上这一层：Search 不再用行 ID 做失效与游标判断。

变更

• TextSearch 记录 document_order_revision_；notify_change 检到 order revision 变化即置位 order_changed_；
• step 在原有 row 校验前先做一次 repair_order()（计一个 work 单位）：找到第一个不再位于自身 rank 的已扫行，只从该处重扫，之前的命中保留；已加载行移动/消失时单独重载；
• rewind / consume / prune / match 的判定从行 ID 改为当前文档 rank与"端点是否仍存活"；有序文档路径与结果顺序不变。

测试

新增 search_reorder_core（4 个场景）：

1. 扫描中重排 → 6 个命中、按 rank 递增、无重复、match() 全存活；
2. 重排后 next/previous 按新文档序移动；
3. 连续换行淘汰最旧行 → 命中只随死行消失；
4. 有序文档的完成状态与命中行不变。

本机隔离 worktree：默认 Release 构建 exit 0；search_core + search_reorder_core + 7 个核心 CTest + Python core 回归 10/10 通过（core 首跑失败仅因隔离构建缺 replay/receive 辅助二进制，补齐后通过）。

证据：README · validation.json

明确未做

• 无 Find/overlay 的 UI 集成、无 Qt 会话或真实 TUI；不改有序增量 Find 的对外语义与预算参数。
• 未测量重排后的重扫/重建成本；仍无用户可达的重排命令或新 VT 模式。
• 不关闭 [R2-04][终端] 实现备用屏、滚动区域及关联模式 #27/[R2][核心基础] 比较稳定行身份与文档顺序的解耦方案 #164，也不声明 R2 通过；任意交错的"重排+淘汰+内容变化"序列未被穷尽。

Refs #27 #164 #169