feat: Add ServerTrace instrumentation hooks to the SSE server

[keelerm84]

Summary

Adds ServerTrace, an opt-in set of callbacks that the SSE Server invokes at points in
its lifecycle, so a consumer can observe per-connection and replay behavior. This is phase 1
of the eventsource server observability work; the OTel bridge that implements these hooks
lives in ld-relay. The library creates no spans and takes no new dependencies -- it only
invokes optional callbacks. The client Stream is untouched.

The design follows net/http/httptrace.ClientTrace: a struct of optional function fields,
exposed as a new Server.Trace field alongside the existing BufferSize/MaxConnTime/Logger
config. Payloads are *Info structs rather than positional arguments so fields can be added
compatibly. A nil ServerTrace, or a nil field within it, disables the corresponding hook.

Callbacks

Callback	Fires when
SubscriberAdded	a subscriber is registered, after the response has been started
SubscriberRemoved	a connection ends, with an exit reason and connection duration
SubscriberDropped	a subscriber falls behind BufferSize and is disconnected
EventSent	an event has been written and flushed to a connection
CommentSent	a comment has been written and flushed
EventDiscarded	a jitter-enabled server coalesces away a pending event
WriteError	encoding or writing to a connection fails
ReplayStarted / ReplayFinished	a Repository replay batch begins / finishes draining

SubscriberRemovedInfo.Reason is a new SubscriberRemovedReason with six values:
client_closed, max_conn_time, write_error, server_closed, unregistered, and
buffer_overflow. Attributing these required threading an exit reason through every read-loop
exit path, plus a closeReason recorded on the subscription by Server.run() before it closes
the subscriber's channel; that channel close is the happens-before edge that makes the
handler-side read race-free.

Request context

Every callback that fires on a subscriber's connection handler goroutine receives that
subscriber's request context as its first argument. It is for telemetry correlation only, such
as attaching a child span to the request span, and must not be used for cancellation. The
context may already be canceled by the time a late callback such as SubscriberRemoved runs,
because the client closing the connection is itself what ends the subscription; that is
expected and does not prevent creating a span from it.

Replay is reported at batch level

Replayed events are encoded in bulk and flushed once per batch rather than individually, so
per-event EventSent would be misleading for them: neither the "has been flushed" contract nor
a per-event WriteDuration holds when the single flush happens only at the end of the batch.
Replay is therefore reported entirely through ReplayStarted/ReplayFinished:

• EventSent/CommentSent fire only for individually-flushed live writes. Replayed events do
  not emit EventSent.
• ReplayFinished.DrainDuration spans through the end-of-batch flush, so the batch flush cost
  is attributed to replay.
• ReplayFinishedInfo.TotalDataSize reports the summed data-payload bytes of the batch,
  preserving payload-size observability now that per-event DataSize is not reported for
  replayed events.

Logging

The same instrumentation points feed Server.Logger when it is set, covering events that are
silent today (only encoder errors are logged): [WARN] on a slow-subscriber drop, and
[DEBUG] on subscriber add/remove and replay drain. No behavior change.

Overhead and payload safety

Timings are computed only when something will consume them, so an unobserved Server reads no
clock and makes no extra allocation on the write path. Sizes are reported as byte counts only;
no callback ever receives an event payload.

Compatibility

The whole surface is marked EXPERIMENTAL and for use by LaunchDarkly libraries only:
callbacks, info fields, and reason values may be added, renamed, or removed in any release,
including a patch release, and the points at which callbacks fire may change.