Improve /hooks UI to show event, matcher, and handler hierarchy

[qqqys]

背景

Claude Code 最新版的 /hooks 展示把 hooks 按三层结构组织：

1. Hook event，例如 PreToolUse、PostToolUse、Stop
2. Matcher group，例如 Bash、Edit|Write、*
3. Hook handler，例如具体的 command/http/prompt/agent 配置

Qwen Code 目前底层数据模型也已经接近这个结构：settings 中是 event -> matcher group -> hooks[]，HookDefinition 也有 matcher 和 hooks 字段。但当前 /hooks 展示更偏向“事件 -> hook 列表”，matcher 这一层不够显性，用户不容易看出某个 hook 到底只作用于哪些工具或触发来源。

建议

建议 Qwen Code 的 /hooks 展示也显式呈现三层结构：

• 第一层：Hook event
• 第二层：Matchers
• 第三层：具体 hook handlers

例如：

PreToolUse
  Matchers
    Bash
      command: /path/to/check-bash.sh
    Edit|Write
      command: /path/to/format.sh
    *
      http: https://example.com/hook

预期收益

• 用户能快速判断 hook 的作用范围，避免误以为某个 hook 对所有事件或所有工具生效。
• 和 settings.json 的真实结构保持一致，降低配置和展示之间的心智差异。
• 后续如果支持更多 matcher 类型、prompt hooks、agent hooks 或 mcp_tool hooks，UI 结构也更容易扩展。
• 对调试 hook 命中问题更友好，尤其是 Bash、Edit|Write、mcp__server__.* 这类 matcher。

兼容性

这应该主要是展示层改进，不需要改变现有 hooks 配置格式。已有的 matcher 为空、* 或未配置的情况，可以归到 * / All 这一组展示。