feat(workspace-cleanup-guard): 提供可配置档位，避免"要么硬拦要么整个关掉"

[cuipengcx90]

诉求

workspace-cleanup-guard 目前没有用户可配置的档位：要么按现状严格执行，要么只能改包内代码、或从扩展加载列表里过滤掉整个扩展才能停掉。希望能提供一个开关，让用户在保留删除保护的前提下，把「无法验证就拒绝」降级为「弹一次确认」。

现状

1. guard 挂在每次 bash / write 调用上，判定为 opaqueDestructiveCommand 时直接返回 block，命令不执行，用户没有补救途径——命中的是「命令文本里出现独立单词 rm」这类形态，改写命令也可能继续命中。
2. 没有任何配置入口：createWorkspaceCleanupGuard() 零参数，index.ts 也不读 flag 或环境变量。
3. 想停掉只能二选一：改包内文件（升级丢失），或在 Pi 的 packages 里用 !extensions/workspace-cleanup-guard/** 过滤（保护一起消失）。中间状态不存在。

同类工具都有档位

工具	可配置入口
Claude Code	permissions.defaultMode（default / acceptEdits / auto / dontAsk / bypassPermissions）+ sandbox.enabled
Codex	approval_policy（on-request / never / granular）+ sandbox_mode（read-only / workspace-write / danger-full-access）
OMP (Oh My Pi)	tools.approvalMode（always-ask / write / yolo）+ per-tool policy + bash.patterns

这三家都把删除保护做成可调档位。guard 是其中唯一没有开关的，而它恰好是唯一会直接阻断命令的。

建议的最小改动

给 guard 增加档位配置（可与其它 OpenPI 配置一同放在 ~/.pi/agent/my-pi-setup.json 或 /openpi-setup）：

• enforce（默认，行为完全不变）：现状，无法验证就 block；
• ask：无法验证时不 block，走已有的 confirmDelete 通路弹一次确认——before() 里已有这条通路，opaque 情况下传空路径列表并给专门文案即可；
• off：跳过 guard。

默认取 enforce 意味着这个改动不改变任何现有用户的行为，也不削弱默认安全性。

背景

在一台真实工作区上，近两天该 guard 共拦截 44 次，其中 41 次走 fail-closed 路径（命令直接失败），其余 3 次是既存文件的确认框。被拦的包括：

rg -n --fixed-strings 'rm -rf' . | head -20
rg -n --fixed-strings 'rm -rf' -g '!*.map' . | head -60
mysql -e "SELECT 1 FROM t_role_menu rm ON 1=1" ; echo done

全部不含删除动作。假阳性部分已由 #624 提出修复；本条针对的是「用户没有任何退路」这一点。

方向与 #497（试点全局 allow / ask / deny）一致。

[627150795]

我来处理这个 Issue，范围限定为 workspace-cleanup-guard 增加 enforce（默认保持现有 fail-closed 行为）、ask（opaque 情况走现有确认流程）和 off 三档配置，并补齐对应测试。配置入口先沿用仓库现有设置方式；不扩展成全局权限策略，也不重复 #624 的 rm 文本误报修复。