chore(webhook): pin local-webhook 0.10.1 so green CI stops spawning sessions

[defangdevs]

The standing watch on this box put four hook-* sessions on defangdevs/agent-box
this afternoon for a repo with nothing wrong: merging #189 emitted a green
check_run.completed per job, a green workflow_run, a Pages deployment, and a run
the concurrency group cancelled. Each session read CI, concluded "nothing to do",
and held one of the four hook-session slots that a real failure needs.

0.10.0 was supposed to have stopped that — its own tool description, INSTRUCTIONS
and the agent-box-webhook --deliver-to help all say a CI event spawns only on a
FAILURE. The implementation only used the outcome to decide whether a CI event
could override ignoreSenders, so with the sender not on the ignore list nothing
was gated. An ignore list names the box's own identity (defangdevs), while CI
is triggered by whoever pushed (lionello), so on this box the brake was never
reached. local-channels 0.10.1 moves the verdict into dispatch_event: a CI
outcome that is not a terminal failure never spawns, whoever triggered it. A
failure still overrides an ignored sender, and session delivery is untouched.

• webhook.rev / webhook.sha256 → local-channels aec22b5 (0.10.1), and
  modules/agent-box.nix regenerated from the .in source.
• tests/webhook.nix gains a leg for it, placed where neither other brake can
  explain the result: the owning session has already handed the topic back and
  the sender is on no ignore list, so only the outcome can hold the spawn. It
  asserts the suppression log line and that no hook-* session appears — the leg
  fails against a pre-0.10.1 pin, which is what makes it a pin test.

Not covered here: the session plugin cache still carries its own copy of
webhook.py (#193), so a session's MCP peer keeps running 0.10.0 until that is
bumped too. Only the dispatcher's copy decides spawns, so the box gets the fix
from this pin alone.

Verification

• nix run .#assemble regenerated the module; nix build of the five
  aarch64-evaluable checks (module-generated-up-to-date, module-single-file,
  webhook-route, download-route, multi-user) passes natively.
• nix eval .#checks.x86_64-linux.webhook.drvPath resolves, so the new test
  script is valid Nix, and check-testscript.sh tests/webhook.nix passes both
  the driver's ty and ruff gates.
• Upstream fix landed as local-webhook 0.10.1: a standing watch spawns for CI only on a failure, whoever triggered it local-channels#12 with 60 unit + e2e tests
  green on python 3.9 and 3.x, mutation-checked.

🤖 Generated with Claude Code

https://claude.ai/code/session_0195u4LJGkuYGkxCQQYEXEK1

[defangdevs]

CI here is red for a reason that predates this branch: memory-protection times out because agent-box-agent.service restart-loops on 226/NAMESPACE, which is master's own state since 7b687b9 — run 31016454644 fails identically, on the same derivation (yl2vfpk8clxpli20xc4l0jrgr6sh9m9v-vm-test-run-agent-box-memory-protection.drv), so this branch cannot have influenced it. #198 fixes it and is green; this needs a re-run once that lands.

The leg this PR actually moves is green: vm-test-run-agent-box-webhook finished in 47.89s, including the new green-CI brake assertion.

Not merging this myself — it changes what the next nixos-rebuild deploys.

🤖 Generated with Claude Code

[defangdevs]

Heads-up: #199 bumps the pin straight past 0.10.1 to local-channels 74a99dd (0.11.0, which contains the 0.10.1 brake unchanged for rule-less watches) and adds the policy half (#197). If #199 lands first, the pin change in the PR attached here becomes redundant — its green-run VM test is still worth landing as-is, since the rule-less watch it exercises keeps the failures-only brake.

[defangdevs]

CI was red on memory-protection, not on anything this PR changes: the agent unit never started (226/NAMESPACE, /var/lib/agent-box-sites/agent: No such file or directory), inherited from 7b687b9 on master. The webhook leg this PR adds — the green workflow_run logging "no failing outcome" and spawning no hook-* session — passed in the same run.

The fix already exists as #198 (green). Rather than duplicate it, this branch is now rebased on fix/sites-rwp-web-disabled and the PR base is retargeted there, so the diff shown here stays just the pin. GitHub will retarget it back to master automatically once #198 merges — so merge #198 first, then this.

nix run .#assemble after the rebase produces no diff, so the generated module and its .in source agree with both changes applied.

[defangdevs]

Recurrence, 2026-08-10 08:03 UTC. The box is still on 0.10.0, so green CI still spawns.

Three green runs on master arrived together:

• Refresh NixOS AMIs — schedule, success (31368403484)
• Publish CFN template to S3 — workflow_dispatch, success (31368420744)
• pages build and deployment — success (31368420174)

That batch started two hook sessions, hook-defangdevs-agent-box-ecd5 (08:03:45) and hook-defangdevs-agent-box-41e1 (08:04:46). Both read the same three green runs. Nothing was wrong in the repo.

Two details this run adds to the PR body:

1. The trigger was a cron, not a push. No human touched the repo. ignore_senders cannot help here at all, because the sender is github-actions[bot]. Only the outcome gate that 0.10.1 moves into dispatch_event stops this event.
2. The session ownership brake did not stop the second spawn either. 41e1 spawned 61 seconds after ecd5 took the topic. That is Standing watches put a second agent on work a hook session already owns #192, seen again.

Slot cost is now 3 of 4. The third slot holds hook-defangdevs-agent-box-d1b9, a session from 2026-08-05 14:5x. It sits at an interrupted prompt and does no work. It has held a slot for 5 days. That is #170. I did not remove it, because it is not my session.

This pin is blocked behind #198, which is green and still open. #199 supersedes the pin, and its CI is red for the same memory-protection reason. So the whole chain waits on one merge.

🤖 Generated with Claude Code