feat: 支持开发板锁在 Cancel 时自动释放并补充使用文档（fix #12）

[yoinspiration]

背景

当前多组织共享同一块开发板时，通过文件锁保证同一板卡上的 Job 串行执行。但一旦某个正在持锁的 workflow 被手动 Cancel，可能遗留“幽灵锁”，导致后续等待同一板卡的 Job 长时间卡在 Waiting for lock，Cancel 也无法真正打断等待。

关联 Issue：#12。

变更内容

• 新增锁监控脚本

  • 新增 runner-wrapper/lock-watcher.sh，在宿主机周期性检查指定仓库下的 Actions Run 状态：
    • 从 ${RESOURCE_ID}.holder 读取当前持锁 run_id。
    • 调用 GitHub API 读取对应 run 的 status 与 conclusion。
    • 当检测到 status=completed && conclusion=cancelled 时，强制清理 ${RESOURCE_ID}.holder 及相关 .release 文件，释放板卡文件锁。
  • 使用 Fine-grained PAT（Actions: Read-only）进行只读访问，最小化权限。

• 补充使用文档

  • 新增 docs/board-lock-watcher.md：
    • 说明 Runner 端 .env 如何启用 board 级文件锁。
    • 说明在宿主机如何配置 .env.watcher、安装 jq 并启动 lock-watcher.sh。
    • 给出多组织共享同一块板卡的完整验证流程。
    • 明确“默认每个参与共享同一块板卡的仓库各启动一个 watcher 实例”的推荐用法。
  • 在 docs/多组织共享Runner使用说明.md 中补充：只有设置了 RUNNER_RESOURCE_ID_PHYTIUMPI / RUNNER_RESOURCE_ID_ROC_RK3568_PC 的板子才会启用 runner-wrapper 与锁目录挂载，未配置的板子仍使用默认 run.sh，不参与锁协调。

行为效果

• 多组织共享同一块板卡时：
  • 正常情况下仍通过 pre-job-lock.sh / post-job-lock.sh 实现按 Job 串行访问。
  • 当持锁的 workflow 被 Cancel 时，watcher 能在检测到 run 变为 completed + cancelled 后主动清理解锁文件，避免后续等待 Job 永久阻塞。
• 对未启用板卡锁机制的 runner 行为无影响。

使用与部署建议

• 对每个参与共享同一块板卡的仓库，各配置一份 .env.watcher 并启动一个对应的 lock-watcher.sh 实例。
• 建议基于 systemd / tmux 等方式将 watcher 以守护进程方式常驻在宿主机上。