用途与定位：quick-tunnel 是一个 worker，仅当开发中的 webhook 服务需要一个公开的临时 HTTPS URL 时使用。它通过 iii 获取并观察 operator 授权的 cloudflared Quick Tunnel 的到期租约，但不允许用户自行选择任意源站，也不负责管理进程。
主要能力：提供 quick-tunnel::acquire、quick-tunnel::release、quick-tunnel::status 四个操作项以及触发类型 quick-tunnel::changed。acquire 需要稳定的不透明 consumer_id、授权的 tunnel_id 和未来的 RFC3339 expires_at；不接受源站、端口、可执行文件、参数或凭证。重复 acquire 会续订同一租约，不会缩短到期时间。status 用于在 acquire 后读取一次以恢复竞争条件，仅在状态为 ready 时使用 public_url。starting 和 reconnecting 不算失败，但尚未就绪；failed 包含经过脱敏的诊断信息。不要轮询，应改为对 changed 事件作出反应。
使用方式：在获取租约前，先注册一个有界 changed 绑定，按 tunnel_id 过滤（默认 webhooks），保留回调元数据与命名空间，并使用引擎的唤醒原语处理后续工作。完成后应释放自己的租约，绝不可释放其他 consumer 的租约；最后一个租约释放后子进程会停止，没有 agent 时到期也会自动结束。不再需要的绑定应注销。新的进程代际是不透明 UUID，可能改变 URL；GitHub 集成必须在 ready 代际变化时更新其 webhook，并在 HTTP 接收端校验 webhook 签名。引擎重连后需核对状态；事件是尽力而为的，回调不是持久队列。配置集中管理，变更在 worker 重启后生效。
适用场景与限制：获取租约会使配置的整个本地服务公开，因此必须要求用户批准。cloudflared 前置条件由 operator 提供，本 worker 不提供；缺少前置条件是真实可观察的失败。Quick Tunnel 没有 SLA，不是生产端点。status 不暴露 Cloudflare 密钥，但 consumer_id 本身也不应包含密钥。不得自行运行 cloudflared 或下载二进制，也不得暴露引擎端口或自主扩大目标允许列表。