fix(fork): 修正 fim_edit 与 update_plan 的 capability 标志

[asto18089]

背景

提示词审查（#4）的附带核查发现两处工具 capability 标志与 ToolCapability 文档语义矛盾：

• ToolCapability::ReadOnly 文档语义："Tool only reads data, never modifies state."
• ToolCapability::WritesFiles 文档语义："Tool writes to the filesystem."

变更

• fim_edit：声明 [ReadOnly, WritesFiles, RequiresApproval]，但 execute 步骤 7 实际 write_atomic 写回目标文件——ReadOnly 自相矛盾，删除。WritesFiles 保留且必须保留：repo_law.rs 的 WRITE_TOOLS 注释明确记载 "fim_edit was such a hole (it declares WritesFiles, takes a path, and fs::writes to it)"，写门控依赖其写工具身份。
• update_plan：声明 [WritesFiles]，但 execute 只锁 plan_state 更新内存快照（_context 均未使用），不写任何文件，删除 WritesFiles。
• 各补一条 capability 回归断言测试。

生产面影响分析（为何安全）

• 两工具的 approval_requirement 都是显式覆盖（fim→Suggest，plan→Auto），不走 capabilities() 的默认推导，审批行为不变。
• is_read_only() 前后取值不变（fim 含 WritesFiles 本就为 false；plan 不含 ReadOnly 本就为 false）。
• repo_law 门控按工具名（WRITE_TOOLS）而非 capability，不受影响。
• filter_by_capability 无生产调用方（仅测试）；plan 模式工具门控按名字段（tool_catalog.rs、engine/tests.rs 的 plan_state_tools 排除清单）而非 capability。
• 唯一可见变化：command_palette 的工具标签朝正确方向修正（fim 不再可能被误标 read-only 路径——实际该路径本就因 is_read_only 为 false 不可达；plan 不再显示 "writes" 标签）。

验证

• cargo test -p codewhale-tui fim/plan/plan_mode/forkguard_ --lib 全过（新增 2 条断言通过；plan 模式注册测试 11 项全过）
• cargo clippy -p codewhale-tui --lib 无新增告警
• 父仓 ./scripts/fork-guard.sh --fast 指纹层全过
• 本地 repo_law:: 模块 8 项失败为 macOS TempDir 符号链接（/var→/private/var）导致的环境性既有失败，在未改动基线 pinvou3-clean 上复现完全一致，与本次改动无关

已知风险与后续

• todo_add / todo_update / todo_write（checklist/work_update 别名同理）同样只写内存状态却声明 WritesFiles，属同类问题；engine/tests.rs 的 plan 模式测试已将这批"plan state tools"按名排除，说明维护者知情。改动面更大，留待后续单独决策，本 PR 不动。
• 两文件均为上游文件，修复属上游通用问题，建议回馈上游；fork 侧登记在合入发标签后随父仓 gitlink 对齐一并更新 docs/fork-modifications.md。

Signed-off-by: asto asto18089@126.com

[github-actions]

Thanks @asto18089 for taking the time to contribute.

This repository is observing a maintainer-managed PR intake gate in dry-run mode, so this pull request is staying open. This note helps maintainers prepare the allowlist before any enforcement is considered.

Please read CONTRIBUTING.md for the expected contribution shape. A maintainer can grant recurring PR access by commenting /lgtm on a pull request.