Api Request Logs Create Create

Centralized respan_params initialization and backward-compat layer. This mixin is the SINGLE initialization point for ``respan_params``. It runs ``_initialize_respan_params()`` BEFORE ``super().initial()`` so that by the time the throttle runs, ``respan_params`` is a fully resolved dict. Downstream code (throttle, preprocessing, view handler) only **enriches** the existing dict — they never need to create it. Initialization order:: _initialize_respan_params() ← legacy rename + header parse + metadata ↓ super().initial() ← throttle ENRICHES the existing dict ↓ view handler ← billing, security strip, etc. Responsibilities consolidated here (previously scattered across 4 callsites): 1. Legacy header rename (X-Data-Keywordsai-Params → X-Data-Respan-Params) 2. Parse X-Data-Respan-Params header (base64 → dict) 3. Legacy body rename (keywordsai_params → respan_params) 4. Form data handling (JSON string → dict) 5. Metadata nesting (passthrough endpoints — Anthropic, Google, etc.) 6. Merge: {**header_params, **body_params} (body wins on field conflict) 7. Add request_url_path from request.META['PATH_INFO'] 8. Guarantee request.data[RESPAN_PARAMS_KEY] is always a dict Safe for protobuf endpoints: body adaptation is skipped when request.data is not a dict; header adaptation always runs. Usage:: class MyChatView(AdaptRespanParamsMixin, APIView): ...