Provide the typed in-process host bridge #51

Acceptance Criteria

• Invoke the existing prepare/run_auction engine through host-supplied services, validated snapshots, budgets and deadlines, returning typed bid/targeting results.
• Preserve shared privacy/authorization and bidder attribution; do not introduce a sidecar, loopback hop, second HTTP app, separate signer or runtime plugin loader.

Host-Owned Configuration: Consolidated From #135

#135 is superseded by this existing bridge issue and #76, not by a second configuration implementation. Auctioneer already exposes its shared concrete policy and validator, resolution functions and the portable engine entrypoint. These are reusable foundations, not proof that Trusted Server is already integrated.

• Bind the host's validated single runtime policy to the existing prepare/run_auction path, using the same typed defaults, bidder-owned validation, account/bidder/privacy resolution and authorization semantics as standalone use. Reuse existing APIs; add only the reviewed bridge glue actually needed by the pinned host contract.
• Borrow or retain the host-owned accepted snapshot and secret/resource services for their required lifetimes, using existing host deployment facts, budgets and deadlines. Do not add a separate Auctioneer startup configuration, loader, source selector, mandatory private config store, second HTTP App, loopback hop or provider-SDK dependency in the portable engine.
• At this bridge boundary, test independently varied operator/account/bidder/privacy/secret policies using two isolated host-supplied snapshots and one compiled engine, including invalid input, snapshot changes and cancellation. Reject process-global operator fallbacks or cross-host state leakage. Actual Trusted Server execution of the contract belongs to Link the bridge into an actual Trusted Server artifact #76; reuse matching observations rather than duplicate the same test under two issue names.
• Re-run the applicable ownership/accounting controls if the final bridge changes storage or lifetime, preserving existing workload limits, resource ceilings and shared accounting. Completed Account for runtime-owned configuration and bootstrap limits #130 is the baseline, not another implementation prerequisite. Actual artifact and host-service identities remain explicit in Link the bridge into an actual Trusted Server artifact #76.

These transferred criteria remain open. Source/API availability and standalone SDK wiring do not demonstrate the actual linked-host outcome.

Blocking And Review Gates

• Blocked by: #34.

Use native blocked-by/blocking links for unconditional issue relationships. Conditional target gates are not universal blockers; link only the selected applicable path after its contract is frozen.

Shared Acceptance Requirements

Every implementation issue ships its own unit/conformance, failure, resource and privacy tests. A later integration issue does not postpone those checks. New untrusted decoders include generated hostile-input controls; changed hot paths include repeatable measurements. Use the existing engine, host services, validated config/push path and EdgeZero handler registration. Preserve privacy, authorization, cookie integrity, HTTPS/SSRF protections, deadlines, exact sent coverage, authoritative bidder/alias attribution and bounded work/storage. Standalone and embedded behavior share policy rather than fork implementations.

No issue may claim a missing capability from metadata import, compilation, observed allocations, a signed cookie, or a different artifact's old evidence. New public/configuration behavior requires its reviewed design before execution. No workload reduction, raised ceiling or replacement budget equation is implied. Bodies and evidence must not publish credentials, identifiers, raw consent, private provider addresses or customer configuration.

Technical Ownership

Sources: roadmap section 7, vision and the existing shared engine/host interfaces.

Approved Integration Contract

PR #152 merged the specification and delivery plan at 9b83deaa680ad8e867169db3b4ebb195b8a1b33c. Their shared requirements apply: whole-catalog reports with verified skipped: not_implemented rows, positive qualification of every implemented identity/alias on all four adapters, existing build discovery and the qualified common native_only retirement. The first Trusted Server host remains Fastly display; Trusted Server #1505 coordinates host-owned work. The planning merge is not implementation or qualification evidence and changes no workload limit, resource ceiling or configuration mechanism.

Reviewed Bridge Package

• Freeze and review the public typed API and its lifetime/resource owners before implementation, deriving it from current canonical preparation, private HTTP application assembly and the shared engine rather than copying them.
• Expose actual engine-selected local candidates/tie facts and targeting for outer host competition; do not rerank all accepted local bids through an unrelated CPM-only reducer or reconstruct selection from targeting strings.
• Preserve the original host deadline, owned start/collect/abandon behavior, exact-once release, and host-deny/engine-deny intersection using real compatible host services. The one accepted runtime policy remains the sole operator-config path.

Actual host-plan/local-executor changes stay with Trusted Server #1505; final linked-host delivery belongs to #76. Writing/reviewing this bridge is not blocked by completing unrelated adapter or publisher work.

Source Contracts

• Approved roadmap
• Product vision
• Issue ledger and qualification limitations
• Schema qualification record