feat(scripts): Docker-only end-to-end /e2e command for example-libpng

[ret2libc]

What this adds

A Docker-only end-to-end smoke test of the full Buttercup pipeline against
example-libpng — no
Kubernetes/minikube. Mirrors the milestones in
.github/workflows/system-integration.yml but tails docker compose logs.

• scripts/e2e.sh — brings the dev/docker-compose/ stack up, submits the
  canned libpng trigger_task, and waits on the pipeline milestones
  (fuzzer build → POV submitted → POV accepted → seed-gen → patch
  generated/approved/passed → bundle submitted; optional SARIF).
• make e2e (and make e2e E2E_ARGS=...).
• .claude/commands/e2e.md — /e2e slash command wrapper.

Flags: --budget (LiteLLM per-user max budget, default $3),
--task-duration, --image-tag / BUTTERCUP_IMAGE_TAG, --no-pull,
--keep-up, --skip-wait, --sarif, per-phase timeout overrides.

Image source

By default the stack runs the prebuilt GHCR images via the
compose.prebuilt.yaml overlay (nothing built locally). --no-pull skips the
docker compose pull and uses already-present images (e.g. locally built and
tagged ghcr.io/trailofbits/buttercup/*:<tag>).

.env handling

e2e.sh regenerates dev/docker-compose/.env each run. It resolves each
value as environment → existing .env → placeholder, so manually-set
values (e.g. LANGFUSE_*) are preserved across runs instead of being
clobbered with empty/placeholder.

Dependency / merge ordering

The prebuilt path invokes
docker compose -f compose.yaml -f compose.prebuilt.yaml. The
compose.prebuilt.yaml overlay is not in this PR — it lives on the
separate compose-prebuilt branch/PR. This PR should land after or together
with that one; on its own the overlay file must already be present in
dev/docker-compose/.

Scope

e2e tooling only — .claude/commands/e2e.md, Makefile, scripts/e2e.sh.
Independent of the three pipeline fixes surfaced while building this
(buttercup-ui internal port, litellm budget enforcement, patcher task
storage), which are their own separate PRs.

Validation

This tooling was used to drive the pipeline end-to-end during development:
fuzzer build → POV submitted → POV accepted, through seed-gen and patch
generation, with budget tracking and Langfuse tracing.

🤖 Generated with Claude Code

[ret2libc]

Addressed CI lint/static failures in 5210208 (shellcheck SC2015 in scripts/e2e.sh).

[hbrodin]

LGTM. One inline note on TASK_ID parsing — fragility, not a current bug.

[hbrodin]

The inline comment on the previous line says "Task id is inside the first [...] block, after the last :" — but the regex does the opposite of both: s/.*\[\([^]]*\)\]/\1/ uses greedy .* and so captures the last [...] block, and s/^[^:]*:// strips up to the first :.

It works today because log_entry() in orchestrator/src/buttercup/orchestrator/scheduler/submissions.py emits exactly one bracketed [{idx_msg}{task_id}] per line, and task_id contains no :. If anyone formats another bracketed token into the log message (e.g. appends bracketed context, or adds a field to MaxLengthFormatter's format string in common/logger.py), this silently captures the wrong block; the subsequent curl .../v1/task/${TASK_ID}/patch/${PATCH_ID}/approve would then return 404 → patch-approve: HTTP fail with no diagnostic pointing back to the parse.

Repro: printf '%s\n' '… [2:taskid] … extra [foo:bar]' | sed -n 's/.*\[\([^]]*\)\].*/\1/p' | sed 's/^[^:]*://' yields bar instead of taskid.

Either tighten the regex (e.g. match a single \[[^:]+:[^]]+\] rather than .*\[…\]) or update the comment to match what the code actually does.