Disable gateway response buffering for model services

[pentaoa]

Summary

Fixes #4269.

• Persist a gateway-only proxy_buffering property on services and disable it when registering a model service (both OpenAI and TGI formats).
• Pass the property into the Nginx service configuration and render proxy_buffering off; in the named service location that forwards regular HTTP requests to replicas.
• On gateway startup, derive the property for previously saved services from their associated models, persist it, and regenerate their configurations. Existing services do not need to be redeployed. Services without models retain the default buffering behavior.

This follows the issue's proposed scope. It does not change the server registration API, request buffering, WebSocket handling, or read timeouts. Disabling response buffering also applies to non-streaming requests to model services: a slow client keeps the upstream connection occupied while downloading the response instead of allowing Nginx to spool it.

Validation

Added tests that exercise service and replica registration through the gateway API and inspect the generated service location for OpenAI, TGI, and non-model services. Added startup coverage loading an old state file without the new field, checking project-scoped model association and persistence across two restarts.

Before the fix: 4 failed, 1 passed; all four model-service cases failed because the generated configuration omitted proxy_buffering off;. The non-model control passed.

After the fix:

uv run --no-sync pytest -q src/tests/_internal/proxy/gateway src/tests/_internal/proxy/lib
62 passed in 3.61s

Ruff 0.12.7 check and format checks passed for all five changed Python files; git diff --check passed.

These tests use the existing SSH/Nginx system mocks and execute the actual configuration renderer and state-file recovery. I did not run a real Nginx/TLS gateway or measure TTFT locally, and did not run GPU/model workloads or the full server suite.

AI-assisted implementation and tests; I reviewed the changed registration, rendering, and startup paths and ran the validation described above.

[peterschmidt85]

@pentaoa we don't accept PRs if the implementation is not discussed first and the author that submits the PR is not actively using dstack.

[pentaoa]

@peterschmidt85 Thanks for clarifying, and apologies for not discussing the implementation with you first. I’m not currently an active dstack user, so I understand these PRs don’t meet your contribution requirements. I’ll hold off on further submissions.