refactor(conversations): drive on_request dispatch from request-body metadata

[leseb]

Summary

Branch the Conversations on_request hook on the shared operation registry's has_request_body() metadata instead of enumerating the body-carrying operations (Create/Update/CreateItems) inline, so the registry is the single source of truth for request-body handling. Header-phase dispatch is split into two boxed helpers — begin_body_operation (arms StreamBuffer buffering, then dispatches a pre-read body) and dispatch_read_operation (the bodyless read handlers) — so on_request keeps a small stack frame. This is the increment of #742 unblocked today on top of the shared match_operation delegation landed by #772; full consumption of an openai_operation classifier (the issue headline) still depends on #744, which has not landed.

Related issue

Refs #742 (partial — headline blocked on #744)

Validation

• Unit tests — cargo test -p praxis-ai-apis (2586 passed, 0 failed, 27 ignored; +2 doctests)
• Integration or functional tests — N/A: behavior-preserving refactor, no new capability; covered by the existing crate suite
• make lint — passes (clippy, nightly fmt, deps, docs, example checks)

Checklist

• I reviewed every changed line and can explain the change.
• New capabilities include an example config and functional example test. — N/A (internal refactor, no new capability)
• User-facing behavior and generated documentation are updated. — N/A (no user-facing or documented behavior change)
• Performance-sensitive changes include appropriate benchmark or load-test evidence. — N/A: neutral-to-positive; shrinks on_request's stack frame (previously tripped the large_stack_frames = deny clippy gate) via boxed dispatch
• Commits are signed and include a Signed-off-by trailer.

Breaking changes

None. The change is behavior-preserving: the same operations arm body buffering and the same read operations dispatch from the header phase; only the decision source (registry metadata vs. an inline operation list) changed.