Implement integrations crate split and ordered configuration

[aram356]

Description

Track implementation of the design in draft PR #1194: #1194

Use the single spec in that PR as the implementation contract. PRs #1084 and #1016 are historical context, not authoritative direction. Capture the post-prerequisite main baseline and behavioral goldens before extraction.

Milestones

• Crate boundary: introduce trusted-server-integrations and trusted-server-integrations-js; move concrete Rust and browser integration sources, assets, and tests into their respective crates. Keep core and browser core neutral. Preserve the existing operator schema and behavior through the temporary normalizer.
• Ordered configuration: adopt one ordered [integrations] inventory with explicit enabled and auction providers nested under their owning integration. Preserve declaration order through CLI push, stored schema 2, and runtime. Complete migration, dual-read compatibility, and adapter-specific rollout/rollback gates.

Done when

• Each milestone meets its exit criteria in the spec; behavior-preserving moves are reviewed separately from intentional configuration and ordering changes.
• Adapter, CLI, browser, cache, and auction behavior is verified against the baseline except where the spec explicitly changes it; the repository's CI gates pass.
• Schema-2 activation and schema-1 rollback are proven with the spec's per-adapter checks and live-config compatibility gates. Do not cut over an adapter while its safety gate is blocked.

Scope guardrails

No plugin ecosystem, dynamic runtime loading, one crate per vendor, public integration SDK, or unrelated refactor.

Affected areas: Integrations, Core, HTML processing / JS injection, JS build pipeline, adapters, Documentation, and CI / Tooling.