Decide and enforce imp_ext reserved-field protection #1143

Context

The standard auction profile accepts static request_ext and imp_ext JSON objects. reject_reserved_fields in crates/trusted-server-core/src/auction/profile.rs blocks trusted_server in request_ext but defines no reserved member for imp_ext. The generated OpenRTB request copies those objects into request and impression extensions. Current configuration documentation states this exact asymmetry; the PR #1049 finding that earlier docs claimed protection for both is historical.

Desired outcome

Make an explicit decision about whether any imp_ext member belongs to Trusted Server or another protected namespace, and enforce and document that decision consistently. Do not add a guard merely for symmetry when no reserved impression member is defined.

Scoped work

• Identify any impression-extension keys that Trusted Server writes or plans to reserve, with the code path or contract that establishes ownership.
• Decide whether imp_ext needs a reserved-key rule. If yes, reject conflicts at config validation and document the key set. If no, state that no keys are reserved and keep the existing accepted behavior.
• Add positive and negative validation tests for the selected rule, including request_ext.trusted_server as the existing comparison.

Done when

• The reserved-key decision and rationale are recorded in configuration and auction documentation.
• Tests prove an allowed imp_ext value survives into the OpenRTB impression and any reserved value is rejected, if a reservation is chosen.
• Documentation and validation agree for both extension objects.

Evidence

Original PR #1049 finding; current crates/trusted-server-core/src/auction/profile.rs, auction/openrtb.rs, and docs/guide/configuration.md at 666953a0d.