test(skillopt): full-chain canary lifecycle E2E (#484)

[jerryfane]

What this drives

A deterministic, NO-LLM, no-network full-chain integration E2E for the #484 canary lifecycle (internal/cli/canary_e2e_test.go). It exercises the canary lifecycle end to end in one flow:

1. Fixture — install planner v1 (champion, current) and drive the REAL runCandidateNotify in canary mode so v2 becomes a live canary row behind the still-current champion (the prod promote path, not a hand-written CanaryPromote). Asserts the champion stays current.
2. Routing leg — a real workflow.Mailbox{CanaryEnabled: true} with a deterministic injected CanaryRand. Each Mailbox.Enqueue resolves the template through templateSnapshot -> routeCanary; draws below the sample resolve the CANARY snapshot, draws at/above resolve the CHAMPION (asserted via the resolved commit on the persisted job payload).
3. Attribution + rollback leg — the canary-routed job payloads are fed through the REAL canaryRegressionHarvester.Harvest() (the Promotion follow-on: canary + auto-rollback for auto-promote #484 decorator wrapping the genuine Mode A: automatic trace-harvested feedback for implement agents (verifiable outcomes → SkillOpt) #465 skillopt.OutcomeHarvester), NOT evaluate() directly. The inner harvester attributes each outcome to the canary version's OWN auto-trace run (skillopt.AutoTraceRunID(canaryID)) via the same UpsertFeedbackEvent path prod uses — the canary run is never hand-seeded. With regressing outcomes the canary is rejected, the prior champion stays the live current version, and candidate.rolled_back fires exactly once.
4. Graduate mirror — healthy real-CI canary outcomes (via a tiny CombinedStatusReader stub) graduate the canary to current with candidate.auto_promoted once.
5. Dedup — two racing Harvest() calls crossing min_samples emit rolled_back exactly once (the changed-bool gate over the idempotent RejectAgentTemplateVersion).

Why it fails if the integration breaks

The two seams the existing candidate_canary_test.go (calls evaluate() with hand-seeded canary feedback) and mailbox_test.go (routing in isolation) bypass are genuinely connected here: routing produces the persisted job payload whose resolved commit is fed back into the harvester. If routing stopped sending sampled traffic to the canary (or the harvest stopped attributing a canary-routed outcome to the canary version's run), the canary's auto-trace run would be empty — so assertCanaryFeedbackCount fails and the regression window holds (no rollback/graduate), failing the state and event-count assertions. Verified by a temporary mutation (forcing routeCanary to never route): the routing-split assertions fail immediately. Avoids a hollow test that would pass if routing or attribution were no-ops.

Test only

No production behavior changes. Uses only the existing injection seams (Mailbox.CanaryRand, the real harvester constructor) and a small offline CombinedStatusReader stub for the strong-positive merge band.

Relates #484.

Gate green in the worktree: go build ./..., go vet ./..., go test ./internal/cli/ ./internal/workflow/ ./internal/skillopt/ ./internal/db/, and go test -race ./internal/cli/ ./internal/workflow/.

🤖 Generated with Claude Code