fix: remove custom server upgrade listener on close

[lprnmns]

Problem

When @fastify/websocket is configured with options.server, it registers its upgrade listener on that supplied server. On fastify.close(), cleanup currently removes the listener from fastify.server instead. If the supplied server remains running, later upgrade requests are routed through the closed Fastify instance and receive a stale 503 response.

Fix

Remove the plugin upgrade listener from websocketListenServer, the same HTTP/S server selected during setup. This preserves unrelated upgrade listeners on a shared server.

Tests

• node --test --test-name-pattern="custom server on close" test/base.test.js — failed before the fix with 1 !== 0; passed after the fix (1 test)
• npm test — passed; 61 unit tests, 100% reported coverage, 65 TypeScript assertions
• npm run lint — passed
• node --check index.js && node --check test/base.test.js && git diff --check — passed
• npm run benchmark --if-present — passed; no benchmark script is defined

Compatibility

This changes cleanup only for the supported pre-created HTTP/S server option. It does not change route handling or remove listeners owned by other consumers.

Related issue

Independent current-branch reproduction; no existing issue or pull request matched after searches for custom server, external server, server option, upgrade listener, listener cleanup, and Fastify close behavior.

[aoede3]

Independent confirmation of this from a different symptom path.

Setup: a never-listened http.createServer() passed as options.server, alongside another upgrade consumer on the Fastify server, plugin 11.3.0. Checked listenerCount('upgrade') on the supplied server at each stage of the lifecycle:

before register = 0
after ready = 1
after app.close() = 1

So the listener installed by the plugin survives close. With a custom preClose that also does server.removeListener('upgrade', ...) on the supplied server the count returns to 0, and it stays exact 0 -> 1 -> 0 across two boot/close cycles. That matches this PR's change of removing from websocketListenServer rather than fastify.server, and I'd expect the default preClose to give the same 0 with it applied.

Measured while running the plugin alongside Vite's HMR websocket in custom dev setup; with this fix that setup needs no custom preClose.

[mcollina]

lgtm