[Unresolved] Derive default reservation amount from request max_tokens

[eguzki]

Summary

RFC 0021 ships the default reservation amount as a flat constant (uint(5000)) because reliably reading request body fields (requestBodyJSON('/max_tokens')) at the point Reserve needs to evaluate them isn't feasible today. Deriving the default from the request's own max_tokens — a real, protocol-declared upper bound — would be strictly better than a flat heuristic, and is called out as an open question in the RFC rather than a decided design.

This is filed as unresolved/exploratory, not committed scope, per RFC 0021, Unresolved questions.

Context

• Blocked on Envoy/wasm-shim request-body handling at the headers phase: allow_on_headers_stop_iteration was added to let the filter pause at headers and move into body processing, then reverted — Revert "feat(wasm): allow_on_headers_stop_iteration on our PluginConfig" kuadrant-operator#2101.
• requestBodyJSON isn't usable at Reserve time today (request phase, before body is available to the filter in the needed way).

Acceptance Criteria (of the investigation, not an implementation)

• Determine whether/how request body access can be made available at the point Reserve's CEL evaluates reservation.amount, without regressing the issue that caused kuadrant-operator#2101 to be reverted
• Document findings (feasible path, or why it remains infeasible) back into RFC 0021 or a follow-up RFC
• If feasible, scope the follow-up implementation as a separate issue

Notes for reviewers

This is a design spike, not a coded feature — no PR review checklist applies until a follow-up implementation issue is filed.