fix(comply): forward structured adcp_error from failed storyboard steps

[bokelley]

Closes #1679

Summary

When a storyboard step fails with a structured AdCP error (e.g. INVALID_REQUEST with field + details.validation_errors), ConversationTypes.TaskResultFailure.adcpError was silently dropped at the executeStoryboardTask boundary. The testing/types.ts TaskResult had no adcpError field, so every downstream consumer — the runner, storyboard-tracks.ts, and extractFailures() in comply.ts — only saw the human-readable error: string. This left ComplianceFailure.error as either an opaque string or {}, making AAO heartbeat grading and LLM self-correction loops unable to identify the exact fault address without re-running the step.

This PR adds adcp_error?: AdcpErrorInfo as a parallel field alongside the existing error?: string across the full compliance pipeline:

• testing/types.ts TaskResult — new field wired at the root
• task-map.ts executeStoryboardTask — forwards result.adcpError as adcp_error
• storyboard/types.ts StoryboardStepResult — new field propagated by the runner
• runner.ts step result assembly — spreads taskResult.adcp_error; suppressed on expect_error steps (mirrors existing error suppression); deleted on peer_branch_taken regrade (consistency fix caught in pre-PR review)
• compliance/types.ts ComplianceFailure — new field on the primary machine-readable surface
• comply.ts extractFailures() — forwards step.adcp_error into assembled failures

All changes are additive-only. error?: string is unchanged; callers reading it as a string will continue to work. The new field is optional and present only when the agent returned a structured adcp_error envelope.

What was tested

• npm run format:check — passed ✓
• npm run typecheck — pre-existing errors (Cannot find type definition file for 'node', deprecated moduleResolution=node10); no new errors introduced (verified by stash+recheck)
• npm run build:lib — cannot run (no node_modules in CI sandbox)
• npm test — 5 new tests added in task-map.test.ts; 406 pre-existing test files fail due to missing packages (zod, ws, @modelcontextprotocol/sdk) in the no-npm-install sandbox; 2 unrelated test files continue to pass. New tests will pass with npm install — the import chain (task-map → response-unwrapper → zod) is present in the pre-existing baseline failure list, not introduced by this change.

Nits noted (not fixed — out of scope for this PR)

• runner.ts:3307 || short-circuit: if stepResult.error (client-side throw) is non-empty, taskResult?.error (protocol string) is never read. Pre-existing; tracked separately.
• summary.ts deriveReason could prefer adcp_error.code + adcp_error.field when the struct is present. Pre-existing; tracked separately.
• The expect_error suppression design: both "suppress" (current) and "always include" are defensible. Current choice mirrors the existing error gate and avoids consumer confusion on passing steps. Documented in StoryboardStepResult.adcp_error TSDoc.

Pre-PR review

• code-reviewer: approved — drop site correct, expect_error suppression sound, two issues fixed (peer_branch_taken regrade inconsistency, top-level import type in compliance/types.ts); nit on runner-level suppression test noted but cannot be added without npm install environment
• ad-tech-protocol-expert: approved — non-breaking per spec, AdcpErrorInfo is the canonical error shape, minor changeset bump is correct

Triage-managed PR. This bot does not currently iterate on
review comments or PR conversation threads (only on the source
issue). To unblock:

• Push fixup commits directly: gh pr checkout <num> →
  fix → push.
• Or re-trigger: comment /triage execute on the source
  issue.

See adcp#3121
for context.

Session: https://claude.ai/code/session_018694zhanVSMB72JRJEQCwq

---

Generated by Claude Code

[bokelley]

Tracking under #1685 (the SDK is a witness, not a translator). This is the keystone PR — ship this first. While step.error arrives as {}, the other four PRs (#1683, #1681, #1682, #1690) can regress silently because every failure looks identical from the grader. Once adcp_error flows through, the other four become observable in cert runs and any future politeness regression is a tripwire.

[bokelley]

Acknowledged — keystone ordering noted. Holding #1683, #1681, #1682, and #1690 as observability-dependent on this merge.

---

Generated by Claude Code

[bokelley]

Noted — thanks for the sequencing update. Once this merges, #1683, #1681, #1682, and #1690 should be clear to proceed.

---

Generated by Claude Code

[bokelley]

Understood — noted the downstream unblock list (#1683, #1681, #1682, #1690). Nothing to act on here; this PR is ready for merge when you're set.

---

Generated by Claude Code

---

Generated by Claude Code

[bokelley]

Acknowledged — standing by for merge.

---

Generated by Claude Code

---

Generated by Claude Code