Hybrid local UI leaves synchronous Runtime responses open

### Description

The synchronous `/ui/chat` Runtime path creates a streamed `requests.Response` but never closes it on success or failure. The neighboring `/ui/chat/stream` implementation already uses a `finally` block to close the same resource.

### Reproduction

Environment: Windows 11, Python 3.12.13, commit `0890278a6571e4190c1ab8cacd9becc147f74d9c`.

Using a fake response whose `raise_for_status()` raises `requests.ConnectionError`, call `local_ui.chat()` with a configured Runtime endpoint and inspect whether `close()` was called. The endpoint correctly converts the error to HTTP 502, but the response remains open (`closed=False`). The same absence of cleanup applies to successful JSON and SSE returns.

### Expected behavior

Every response returned by `requests.post(..., stream=True)` should be closed on all success and exception paths.

### Impact

Repeated synchronous UI calls, especially failed or partially consumed Runtime streams, can retain HTTP connection/socket resources until garbage collection and eventually reduce connection-pool availability in a long-running demo process.

### Suggested fix

Track the response and close it in a `finally` block, matching the existing streaming endpoint's lifecycle handling. Add regression tests covering both a normal return and an HTTP error.

Start at the local_ui.chat() implementation for the synchronous /ui/chat Runtime path and compare its response lifecycle with /ui/chat/stream. Reproduce the fake-response success and requests.ConnectionError cases, then add regression coverage for both normal and HTTP-error returns. Done means every response from requests.post(..., stream=True) is closed on success and exception paths.

Written by the indexing model from the issue text.