fix(http): address streaming review findings

[NathanFlurry]

• Resolve streaming review annotations around upload completion and response handling.
• Tighten ingress and egress accounting, response queue limits, and related tests.

[NathanFlurry]

Stack for rivet-dev/rivet

• #5518 fix(http): make request handoff ordered and non-resumable
• #5508 fix(http): address streaming review findings 👈
• #5509 fix(http): harden streaming lifecycle and observability
• #5516 feat(http): stream HTTP bodies end-to-end
• main

Get stack: forklift get 5508
Push local edits: forklift submit
Merge when ready: forklift merge 5508

_{change pokxmrox}

[claude]

Review

Scoped, well-motivated follow-up to the streaming-lifecycle PR. Went through request.rs, response.rs, response_queue.rs, handler.rs, shared_state.rs, and the config plumbing.

Correctness

• Merged final request-body chunk (request.rs:165-168): collapsing the trailing partial-flush plus empty-finish marker into a single send_http_request_body_chunk(final_chunk, true) reduces message amplification. I traced this into the actor-side consumer (engine/sdks/rust/envoy-client/src/actor/http.rs::handle_req_chunk) - it forwards chunk.body to body_tx before checking finish, so a non-empty body arriving together with finish=true is handled correctly. Good simplification.
• Reusing a single pinned response_start future across both tokio::select! branches (request.rs:277-302) instead of constructing a fresh wait_for_http_response_start(...) call after the upload branch completes is a nice correctness and clarity improvement, same effect as before but avoids re-deriving state from scratch.
• next_request_body_size to RequestBodySize enum and the if-not-empty restructuring in response.rs are faithful refactors of the old boolean-chained logic; no behavior change found.
• advance_http_stream_message_index wraparound and gap-rejection logic is untouched aside from the added doc comment.

One gap worth a look

gateway_http_response_queue_max_messages() and gateway_streaming_http_response_queue_max_bytes() (engine/packages/config/src/config/pegboard.rs) do not clamp their configured value the way gateway_http_response_body_channel_capacity() does (unwrap_or(16).max(1)). Since these two were previously hardcoded constants and are now operator-configurable, a config value of 0 will make HttpResponseQueueBudget::try_reserve fail immediately on every call, silently blocking all HTTP responses through the affected gateway. Not a bug in the diff's own logic, but worth either clamping to a sane minimum like the channel-capacity getter does, or explicitly documenting that 0 disables response delivery.

Minor / nit

• engine/artifacts/config-schema.json now ends without a trailing newline in the diff. Cosmetic, but worth regenerating cleanly if the generator normally emits one.

Test coverage

• HttpResponseQueueBudget and next_request_body_size/RequestBodySize unit tests were updated in lockstep with the signature changes and still cover the same scenarios (message and byte bounds, overflow safety).
• No new test directly exercises the combined body-plus-finish=true final request chunk end-to-end (verified manually against the actor-side handler instead). Given it changes wire message count, a small integration test asserting the receiver still transitions RequestPhase::Upload correctly would harden this against regressions in either the gateway or the runner-side handler.

Style / conventions

• Matches repo conventions: comments are complete sentences, no fallthrough arm on the enums touched, structured tracing::warn! fields, and the new CLAUDE.md bullets are consistent with the actual code changes (explicit match/if instead of chained boolean logic, and warn/error logs now naming the likely operational cause, e.g. HTTP_RESPONSE_QUEUE_OVERLOADED_DETAIL).

Nothing blocking here; the queue-limit clamping point is the only thing I would actually want addressed before merge.