feat: add closeServer and closePreviewServer hooks

[jamesopstad]

Fixes #22913

Description

Adds two new plugin hooks that let plugins run cleanup when a dev or preview server shuts down:

• closeServer(server, { reason }) — called when the dev server closes. reason is 'restart' (server is being replaced by a restart) or 'close' (server is shutting down for good).
• closePreviewServer(server) — called when the preview server closes. No reason, since preview servers never restart.

{
  name: 'my-plugin',
  closeServer(server, { reason }) {
    if (reason === 'close') {
      // cleanup etc.
    }
  },
  closePreviewServer(server) {
    // cleanup etc.
  },
}

Notes

• The hooks run only once the server has been fully torn down and the HTTP server, WebSocket server, environments etc. have all closed. This means there are no in-flight requests or open connections to race against.
• The hooks are global, async and parallel and use Promise.all. This matches the global configResolved() hook and the per-environment closeWatcher() hook. It may be preferable to use Promise.allSettled but, if so, this behaviour should be aligned across these hooks. Currently a throwing closeServer() hook can lead to unhandled rejections and a dormant server instance.

[sapphi-red]

Would it be possible to extract the signal-exit change in a separate PR?

[jamesopstad]

Would it be possible to extract the signal-exit change in a separate PR?

I've updated this PR to only add the new hooks and I have a separate PR to use signal-exit that I can open once this one's merged.

One thing to flag is that a throwing closeServer hook rejects on restart (after teardown, before the new server listens), leaving the server dormant. The config-change path logs it and the r shortcut surfaces it as an unhandled rejection. Should we handle this differently?

[sapphi-red]

One thing to flag is that a throwing closeServer hook rejects on restart (after teardown, before the new server listens), leaving the server dormant. The config-change path logs it and the r shortcut surfaces it as an unhandled rejection. Should we handle this differently?

The reason why the config-change prevents the unhandled rejection is to avoid the process exit happening when saving a intermediate config file. I think it's ok to keep the difference for this PR. But maybe we should align it.