fix: Stop reporting response bytes that were never written

[keelerm84]

Summary

relay.response.bytes on the relay.response.write span was set before the write, from len(payload), in all five polling handlers, and the write's result was discarded. It reported the payload size under the name of the response.

Measured against a real relay, GET /sdk/flags, 3310-byte payload:

Scenario	relay.payload.bytes (serialize span)	relay.response.bytes (write span)	http.response.body.size (request span)	actual wire body
200, no compression	3310	3310	3310	3310
200, compression on	3310	3310	532	532
304 (If-None-Match hit)	3310	3310	absent	0

The 304 row is the ordinary SDK polling path. A short write or client disconnect was the third divergence: the partial count never appeared and the span status stayed OK, so the span named relay.response.write could not tell a complete response from a truncated one.

Taking the count from w.Write would not have fixed the compressed case. The handler's ResponseWriter is the gzip writer -- the compression middleware is registered outside the handler -- and gzhttp.Write returns input bytes consumed, not compressed output. The truthful count already exists on the request span as http.response.body.size, recorded by the HTTP tracing middleware from a counter outside the compression middleware, which is the only place wire bytes are observable; it is correct in every row above, and correctly absent rather than zero on the 304.

So this drops relay.response.bytes and tracing.ResponseBytesKey. The division of labour is now:

• serialize span -- relay.payload.bytes: what was built.
• request span -- http.response.body.size: what actually went out, after compression.
• write span -- duration, plus two things it was missing:
  • http.response.status_code, so a body-less 304 explains itself instead of looking like a lost payload.
  • RecordError and an error span status when the write fails. This is the load-bearing part: a write that fails once the header is out cannot change the status code, so the request span's status stays unset and the write span is the only place that failure can surface.

The five near-identical write-span closures collapse into one traceWriteResponse helper, which also removes the dupl lint exposure flagged during the review of #784. writeCacheableJSONResponse now returns (status, error).

Tests: the previous payloadBytes == responseBytes assertion was a tautology -- both sides were len() of the same slice -- and goes away with the attribute it compared. New relay_endpoints_write_span_test.go covers the three divergences directly: the 304 path, the compressed path, and a write that fails after the header is out. Mutation-checked -- dropping RecordError, returning 200 on the etag path, or reporting a wrong status code each fail tests.

Also documented in the helper, since it is the same confusion one level down: the span measures the time to hand the payload to the ResponseWriter, not time on the socket -- a response small enough for net/http's output buffer is flushed after the handler returns.

Found by a multi-agent review of #784 (finding #3), which introduced these spans.

Independent of #791 (also open, also off v9): no overlapping files, not stacked.

---

Note

Low Risk
Telemetry-only changes to polling handlers with added tests; no auth, data, or API behavior changes beyond more accurate tracing.

Overview
Fixes misleading relay.response.bytes on relay.response.write spans, which were set from len(payload) before the write and could disagree with what actually went on the wire (gzip, 304, truncated responses).

Removes tracing.ResponseBytesKey and stops attributing byte counts on the write span. Payload size stays on the serialize span (relay.payload.bytes); wire size is left to the request span (http.response.body.size from HTTP middleware, outside compression).

Polling handlers now share traceWriteResponse, which records http.response.status_code on the write span and RecordError / error status when Write fails after headers are sent—cases the request span cannot reflect. writeCacheableJSONResponse returns (status, error) so failures are observable.

Tests drop the tautological payload-vs-response bytes check and add coverage for 304, compression, and post-header write failures.

^{Reviewed by Cursor Bugbot for commit c99115c. Bugbot is set up for automated code reviews on this repo. Configure here.}