Release 0.37.2

[Dim145]

A patch release with one change: the messaging stream now connects immediately
instead of a heartbeat later.

The live stream took up to a minute to open

If you run Trackarr behind a CDN or a buffering proxy, /messaging/events
took about a minute to connect on every page load. It always worked — chat and
notifications arrived once it was up — it was just late, every single time.

The relay sent its response headers at once and then no body byte at all
until its first keep-alive ping, thirty seconds later. A flush with an empty
body produces no chunk to forward, so anything in the path that waits for body
bytes before releasing a response waited. Reported from a Cloudflare-fronted
install whose network trace showed 16 bytes of content on that request:
exactly two pings.

The stream now writes a priming comment the moment the headers go out.
Measured on the first byte of body, before and after:

	headers	first body byte
before	104 ms	30 121 ms
after	116 ms	117 ms

30 121 ms is the heartbeat interval to the millisecond.

The stream also now states its own reconnect delay (retry: 2000) instead of
leaving the browser on a default that differs between them.

Nothing else changed — no behaviour, no data, no configuration, and the
heartbeat interval is untouched. If your reverse proxy already streamed this
endpoint without buffering, you would never have seen the delay and nothing
changes for you.

Upgrading

Swap the relay image. No migrations, no configuration changes. Reverse-proxy
settings need no adjustment: this was ours, not yours.

🤖 Generated with Claude Code