Add reply.sse.signal which lazily creates an AbortController

### Prerequisites

- [x] I have written a descriptive issue title
- [x] I have searched existing issues to ensure the feature has not already been requested

### 🚀 Feature Proposal

Add a new `AbortSignal` at `reply.sse.signal` that provides abort observability on the same conditions as `reply.sse.onClose(cb)`.

This can be passed into modern code that uses abort signals so that they can listen for and track closure, without having to manually create one in the handler.

### Motivation

Fastify added `request.signal` in v5.8.0. This is useful for regular requests but falls short for SSE since it represents an incoming request cancellation and doesn't signal when the SSE context itself ends. This is a relatively safe and lightweight addition that allows us to connect this into modern APIs seamlessly. The creation of the controller for the signal can be created lazily in `get signal () { ... }`.

### Example

```ts
async function * events (signal) {
while (!signal.aborted) {
try {
yield await eventQueue.next({ signal })
} catch (error) {
if (signal.aborted) return
throw error
}
}
}

// with `reply.sse.signal`:
fastify.get('/events', { sse: 'only' }, async (_request, reply) => {
await reply.sse.send(events(reply.sse.signal))
})

// without `reply.sse.signal`:
fastify.get('/events', { sse: 'only' }, async (_request, reply) => {
const controller = new AbortController()

reply.sse.onClose(() => {
controller.abort()
})

await reply.sse.send(events(controller.signal))
})
```

---

Note that I have a PR in progress for this that I plan to post tomorrow, but I would love to hear concerns about the feature itself or how it's defined.

Start by reading the existing reply.sse.onClose(cb) behavior and the reply.sse API entry point. Verify that a lazily created reply.sse.signal exposes an AbortSignal and observes the same SSE closure conditions; the issue notes that a pull request is already in progress.

Written by the indexing model from the issue text.