SseEventSource: HTTP 204 on (re)connect should terminate the event source gracefully instead of reconnecting forever

This issue surfaced while running the OSGi "Whiteboard Specification for Jakarta RESTful Web Services" TCK against a Jersey 4 based whiteboard implementation (eclipse-osgi-technology/jakartarest-osgi): the TCK's SSE test case fails with every Jersey version since 3.1.8, and the root cause turned out to be in the SSE client.

`SseEventSource` currently provides no way for a server to tell the client to stop reconnecting. According to the WHATWG HTML specification for `EventSource` :
> A client can be told to stop reconnecting using the HTTP 204 No Content response code.

Jersey's `EventProcessor` does not implement this. When the handshake request of a re-connect attempt returns **204 No Content**, the client schedules the next reconnect and keeps polling the endpoint forever. The registered `onComplete` callback is never called, except oin the manual `close()` or, since 3.1.8, after an error.

## Why this became visible now

Up to and including 3.1.7 (and 3.0.x before the backport), connection errors during reconnect were silently swallowed and simply shut the event source down. This obviously accidentially acted as "termination signal" for servers that answered a reconnect with
an error status. #5693 fixed that (correctly!) in 3.1.8 by delivering such errors to the registered `onError` consumers.

Since then there is **no response a server can send that terminates the client cleanly**:

| Response on reconnect | Client behavior since 3.1.8 |
| ---------------------- | ------------------------------------------------------------ |
| 2xx stream that closes | schedule next reconnect (forever) |
| **204 No Content** | **silent infinite reconnect loop, `onComplete` never fires** |
| 503 (+ Retry-After) | reconnect |
| any other error status | `onError` + shutdown |

This is exactly the scenario of the OSGi TCK test expoerienced. The server completes the stream, answers the subsequent reconnect with a termination signal, and the client is expected to complete without an error, which doesnt work with the current behaviore.

I already looked into it and would provide a fix PR.

Start with the SSE client’s EventProcessor and trace how a reconnect handshake handles an HTTP 204 response. Use the OSGi Whiteboard Specification for Jakarta RESTful Web Services TCK SSE test case to reproduce the loop. Done means a 204 response during reconnect stops the event source gracefully and invokes the registered onComplete callback without an error.

Written by the indexing model from the issue text.