fix(training-agent): derive media-buy health/impairments from creative status

[bokelley]

Summary

• Adds deriveImpairments() in task-handlers.ts that walks each buy's creativeAssignments and surfaces impairments[] entries from session creative status. Wired into handleGetMediaBuys + handleCreateMediaBuy responses. Creative-track only.
• Adds force.creative_status adapter to buildSalesComplyConfig so storyboards can drive the creative through approved → rejected → processing via comply_test_controller on /sales.
• Fixes handleSyncCreatives: assignments[] entries now fall back to walking session.mediaBuys when media_buy_id is omitted — per sync-creatives-request.json which marks only creative_id + package_id as required.
• Bumps @adcp/sdk ^7.6.0 → ^7.7.0 for the creative_approvals[] extractor on the SDK runner's impairment.coherence buy-snapshot walk (ComplyControllerConfig: add force.audience_status + force.catalog_item_status slots adcp-client#1819).

Why

The official dependency-impairment storyboard (#4677 closing #2860) currently fails on /sales at the get_buy_impaired step because the training agent doesn't emit health + impairments[] on get_media_buys. This PR adds the derivation.

Effect

Moves the official scenario from 3P / 1F / 7S to 6P / 1F / 4S on /sales (three previously-skipped steps now pass; same one failure).

Remaining gap

The one remaining get_buy_impaired failure is blocked on adcontextprotocol/adcp-client#1846 — the v6 SalesPlatform.syncCreatives strips assignments[] from the wire request before reaching the platform handler, so the buy never gets the creative assigned and the derivation has nothing to surface. Once #1846 lands, the scenario fully clears without further training-agent changes.

The defensive media_buy_id fallback in handleSyncCreatives is staged for that fix — it's a no-op today (assignments never reach the handler) but kicks in immediately once the SDK pipes them through.

Scope boundary

• In scope: creative-track. Audience / catalog_item / event_source resource families are forward-only on the spec today (SDK runner's INVERSE_DEFERRED_FAMILIES still includes them).
• Out of scope: audience-track + catalog-item-track variants of the storyboard, failing-case sub-phase, webhook receiver assertion. All tracked in Dependency-impairment storyboard — audience-track + catalog-item-track variants (follow-ups to #2860) #4674.

Test plan

• npx tsc --project server/tsconfig.json --noEmit — clean
• TENANT_PATH=sales npx tsx server/tests/manual/run-storyboards.ts — media_buy_seller/dependency_impairment ✓ 6P / 1F / 4S (was ✗ 3P / 1F / 7S)
• /sales tenant totals: 355 passed (was 350), 19 failed, 167 skipped — net +3 unblocked, +1 unrelated failure shift, no regressions
• Full matrix run in CI

Related

• storyboard: dependency-impact end-to-end scenario #2860 — closed by docs+compliance: terminal-buy carve-out (#4635) + dependency-impairment storyboard (#2860) #4677 (storyboard exists; this PR makes it pass)
• docs+compliance: terminal-buy carve-out (#4635) + dependency-impairment storyboard (#2860) #4677 — landed the storyboard
• Dependency-impairment storyboard — audience-track + catalog-item-track variants (follow-ups to #2860) #4674 — follow-up: audience/catalog tracks + failing-case + webhook
• v6 SalesPlatform.syncCreatives: assignments[] silently stripped before reaching platform handler adcp-client#1846 — SDK gap blocking the last step
• ComplyControllerConfig: add force.audience_status + force.catalog_item_status slots adcp-client#1819 — SDK 7.7.0 force adapter slots (already shipped)

🤖 Generated with Claude Code

[bokelley]

Closing — superseded by #4733 which landed yesterday and implements the same fix (concurrent work).

Comparison:

• feat(training-agent): impairment tracking for media buys (closes #4719) #4733 (merged): push-based — stores Impairment on MediaBuyState.impairments directly; propagateCreativeImpairment runs on forceCreativeStatus and walks session.mediaBuys to append/remove impairment rows. Reads emit the stored list.
• fix(training-agent): derive media-buy health/impairments from creative status #4737 (this PR): pull-based — deriveImpairments() at read time walks creativeAssignments and reads creative status. No stored field.

#4733's approach is canonical (matches the spec's "seller MUST surface" framing where the seller actively pushes the impairment, rather than the buyer's reader inferring). The force.creative_status adapter on /sales and the sync_creatives.assignments[] workaround both landed in #4733 too.

After merging main into this branch, net source delta is zero (merge commit f66943c). The branch can stay open as a worktree-cleanup; closing the PR.

Cross-references preserved on follow-up:

• adcp-client#1846 (SDK gap surfaced) — duplicate of adcp-client#1842 which feat(training-agent): impairment tracking for media buys (closes #4719) #4733 references; will close fix: migration docs #1846 as a duplicate.
• adcp#4674 (audience/catalog track + failing-case + webhook follow-ups) — still open, still useful.
• adcp-client#1848 (SDK PR: audience inverse + creative_approvals walk) — still useful, still draft.