feat(examples): hello_seller_adapter_proposal_mode cascade-scenario sandbox arm parity with guaranteed adapter

[bokelley]

Context

examples/hello_seller_adapter_guaranteed.ts:591-608 has a cascade-scenario sandbox arm that handles the storyboard runner's resolved-sandbox-account case. The proposal-mode adapter (examples/hello_seller_adapter_proposal_mode.ts) lacks the equivalent arm.

Why deferred

Investigation under #1600 found that adding the sandbox arm doesn't actually help proposal-mode storyboards in isolation — the resolved sandbox account id wouldn't match the proposal store's expectedAccountId from prior phases (proposal registered under pub_acmeoutdoor.example). The real fix is the runner-enricher bug filed separately.

This issue is probably moot once that fix lands — leaving as a placeholder in case follow-up testing surfaces a residual gap.

Acceptance

• After the runner enricher fix lands, re-run media_buy_seller/proposal_finalize storyboard against the proposal-mode adapter unfiltered.
• If create_media_buy still fails on cascade-scenario account resolution, add the sandbox arm. Otherwise close as obsolete.

Refs

• fix(adapter): hello_seller_adapter_proposal_mode create_media_buy fails schema validation against AdCP 3.0.7 #1600 (original misdiagnosis — closed)
• fix(test): drop stale get_products_refine allowlist on proposal-mode adapter #1599 (interim allowlist mask)

[bokelley]

Verification — closing as obsolete (Outcome A)

Re-ran media_buy_seller/proposal_finalize against the proposal-mode adapter unfiltered after PRs #1603 (proposal-mode request shape) and #1607 (enricher field preservation) landed on main (@ 6b596e0).

Result: overall_status: passing, failures: []. All five phases run end-to-end.

Phase	Task	Status
setup	sync_accounts	SKIP (sole-stateful exemption — not_applicable, downstream phases run)
brief_with_proposals	get_products	PASS
refine_proposal	get_products	PASS
finalize_proposal	get_products	PASS
accept_proposal	create_media_buy	PASS

create_media_buy reaches the upstream POST /v1/orders + POST /v1/orders/{id}/lineitems routes — the façade gate confirms full traffic.

Why the sandbox arm isn't needed: the proposal-mode adapter's accounts.resolve keys explicitly off publisherDomainFromRef(ref) against KNOWN_PUBLISHERS. The storyboard's acmeoutdoor.example brand is in that list, so pub_acmeoutdoor.example resolves consistently across all phases — finalize registers the proposal under that account, and accept lands create_media_buy against the same account with the proposal-mode wire shape ({ proposal_id, total_budget }) preserved by #1607.

The guaranteed adapter's sandbox arm exists for the broader sales_proposal_mode suite's other storyboards (delivery_reporting, invalid_transitions, pending_creatives_to_start) which invoke comply_test_controller with synthetic refs. proposal_finalize doesn't invoke the controller, so the proposal-mode adapter never sees a synthesised sandbox ref in this storyboard.

The CI gate (test/examples/hello-seller-adapter-proposal-mode.test.js) already runs unfiltered with EXPECTED_FAILURES = [] and passes all three gates, locking in this behavior.

Closing as obsolete per the acceptance criterion. The deferral hypothesis ("probably moot once the runner-enricher fix lands") was correct.