v1.5.11

v1.5.11 — response headers set by middleware after the handler wrote are no longer lost (session cookie, trace context)

A correctness release with two fixes of the same class. Found by the v1.5.10 weekend soak on the bench cluster and reproduced locally.

Fixed

• #507 — the session middleware never issued its cookie when the handler wrote the response. The middleware persisted the session and set Set-Cookie only after c.Next() returned, but celeris writes responses immediately when a handler calls c.JSON/c.String/…, so the header was silently dropped. A login handler of the usual shape (sess.Set, sess.Save, c.JSON(200, …)) returned 200 with the session id in the body and no cookie; every authenticated request that followed was 401. The cookie is now emitted before the body can be written — on the first mutation (Set, Save, Regenerate with the new id, Destroy with the clearing cookie) and, with SaveUnmodified, at load time for fresh sessions — while persistence still happens after the chain. Mutating a session after the body has been written cannot set a cookie and is now documented (and counted). Regression tests cover the login shape, Regenerate/Destroy, SaveUnmodified, duplicate-header prevention, and a native-engine login round trip. This affected every prior release; the v1.5.9 and v1.5.10 soaks showed it as a 96 % 4xx share with a re-login on every request.

• otel: the traceparent response header was injected after c.Next() and therefore never reached the client when the handler wrote a body — the same defect class. The trace context is now injected before the handler runs; the span context is fixed at that point, so the value is identical. (#509)

• celeristest: the response recorder aliased the Context's live header buffer, so a header set after the body was written appeared in test assertions even though it never hit the wire — which is how both bugs above stayed invisible to the unit tests. The recorder now snapshots the wire headers. (#509)

Verification

48-cell nightly and 24 h weekend soak under probatorium's absolute gate (which now also gates property violations and requires the in-process property loop to have run) before the v1.5.11 benchmark publication.