chore(ci): stop auto-dispatching ClaudeBox on #alerts-next-scenario failures

[AztecBot]

What

The nightly/weekly Spartan scenario + benchmark workflows call
ci3/slack_notify_with_claudebox_kickoff on failure, which both posts a Slack
notice to #alerts-next-scenario and auto-dispatches a ClaudeBox
investigation session (via gh workflow run claudebox.yml → the ClaudeBox v2
/run webhook).

This turns off the automatic ClaudeBox dispatch for that channel by
switching those failure steps to plain ci3/slack_notify — the failure is
still announced in #alerts-next-scenario exactly as before, there's just no
auto-kickoff. ClaudeBox can still be triggered manually when a failure warrants
investigation.

Why

The auto-kickoff was firing on every nightly failure and burning a lot of
tokens. Requested by Alex Gherghisan — keep the alerts, drop the automatic
investigations, trigger manually as needed.

Scope

7 failure-path call sites, all targeting #alerts-next-scenario:

• ci3.yml — Nightly Spartan Scenario (tagged runs)
• test-network-scenarios.yml — Scenario tests
• nightly-spartan-bench.yml — Spartan / proving / block-capacity benchmarks (×3)
• nightly-bench-10tps.yml — 10 TPS benchmark
• weekly-proving-bench.yml — weekly real proving benchmark

Each step is renamed to Notify Slack on failure, drops the now-unused
GITHUB_TOKEN env and the (🤖) marker, and keeps the same failure text.

Kickoffs for other channels (#team-fairies, #team-bonobos, #honk-team,
#team-alpha, merge-train/canary) are intentionally left untouched.

Notes

• The nightly jobs execute in aztec-packages-private; these workflow files
  mirror there via the merge train, so the change takes effect once it
  propagates.
• No claudebox-side config change is needed — the trigger lived entirely in
  these CI workflows, not in the claudebox routing config.

---

Created by claudebox · group: slackbot