Bound each SSE write instead of removing the deadline entirely

Gadfly, security lens: clearing the write deadline outright traded the
truncation bug for an unbounded one. With no deadline, a client that stops
reading fills the socket buffer and blocks Write forever — pinning the agent
run goroutine and this stream's mutex, which also takes down the keep-alive
since it needs the same lock. The old 30s WriteTimeout at least bounded that.

Refresh the deadline per frame instead: the stream as a whole is unbounded,
but no single write is. That is the only shape that satisfies both ends, since
an absolute deadline cuts long turns and no deadline cannot be recovered from.

The probe stays in openEventStream so a writer that cannot take deadlines is
reported once rather than once per frame; the per-write call deliberately
ignores its error for the same reason.

Also widened the test's timing margins, per the second finding. tick is now
GREATER than writeTimeout, so every frame lands after the deadline has already
expired and the margin only ever grows — a loaded CI runner pushes this toward
passing rather than toward flaking. Sized the other way it would flake exactly
when CI is busiest. Passes 3/3 with -count=3.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ

internal/api/sse_deadline_test.go

@@ -22,11 +22,15 @@ import (
 // after the deadline return err == nil and their bytes are silently discarded.
 // A test that checked the return of io.WriteString would pass against the bug.
 func TestEventStreamOutlivesWriteTimeout(t *testing.T) {
-	// Long enough that the frames below straddle it, short enough to keep the
-	// test quick. Everything else is scaled off it.
-	const writeTimeout = 300 * time.Millisecond
-	const tick = 200 * time.Millisecond
-	const frames = 4 // last one lands at ~800ms, well past the deadline
+	// tick > writeTimeout on purpose, so EVERY frame lands after the deadline has
+	// already passed and the first one clears it by a full 100ms. The margin only
+	// ever grows: a slow or loaded CI runner delays frames further past a deadline
+	// that has already expired, so scheduling jitter pushes this test toward
+	// passing rather than toward flaking. Sizing it the other way — frames landing
+	// just before the deadline — would flake exactly when CI is busiest.
+	const writeTimeout = 200 * time.Millisecond
+	const tick = 300 * time.Millisecond
+	const frames = 3 // ~900ms total; the last lands 700ms past the deadline
 
 	gin.SetMode(gin.TestMode)
 	r := gin.New()