fix(microservices): close the request-response span exactly once

[kamilmysliwiec]

PR Checklist

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated — N/A, no public API change

PR Type

• Bugfix

What is the current behavior?

Issue Number: N/A

Follow-up to #17781, which fixed this leak on the event path. It raised the same
problem on the request-response path; this is that fix.

On the request-response path the end hook lives in the publisher —
ServerMqtt#getPublisher, ServerNats#getPublisher, ServerRedis#getPublisher,
the inline publisher in ServerTCP#handleMessage, and ServerRMQ#sendMessage.
Server#send invokes that publisher once per emitted packet, and only after
await handler(...) has resolved. Two things go wrong:

1. A multi-value response closes the span once per value. A handler
returning an observable of three values publishes three packets, so
onProcessingEndHook runs three times for one request. Measured on master
with ServerTCP:

multi-value: endHook calls = 3 | sendMessage calls = 3
single:      endHook calls = 1 | sendMessage calls = 1

2. A rejecting handler never closes the span at all. The await throws
before the publisher is ever reached, so the span stays open forever:

reject:      endHook calls = 0 | sendMessage calls = 0

Blast radius on the second one is narrow, for the reason #17781 documented:
handlers registered through the DI pipeline are wrapped by RpcProxy, which
turns a rejection into an error observable, so send publishes an { err }
packet and the span closes. What actually rejects is a custom exception filter
that throws and raw handlers registered via addHandler by custom transport
strategies. The first bug has no such escape hatch — any @MessagePattern
returning a multi-value observable hits it.

What is the new behavior?

Both are fixed the way #17781 fixed the event path. The hook moves out of the
publisher and onto the response stream's finalize teardown, guarded by the
shared Server#createProcessingEndHookRunner added in that PR, and the handler
call is wrapped in try/catch so a rejection closes the span before the error
is rethrown. After the change, all four paths close the span exactly once:

multi-value:  endHook = 1, sends = 3
single:       endHook = 1, sends = 1
reject:       endHook = 1, sends = 0
stream-error: endHook = 1, sends = 1

12 specs across the five transports; 10 of them fail on master. (The two that
pass there are the tcp single-value and stream-error cases, which already fired
once.)

This also lines the transports up with where the hook already fires elsewhere —
Server#handleEvent uses finalize, ServerKafka#sendMessage uses .finally(),
and grpc closes in a finally — so "the span closes when the handler's work
finishes" now holds everywhere.

One deliberate side effect: the NO_MESSAGE_HANDLER path in mqtt, nats and
redis no longer fires an end hook. It never ran a start hook, so that call was
unpaired; tcp and rmq already did not fire one there.

The ctx / context parameters of ServerNats#getPublisher,
ServerRedis#getPublisher and ServerRMQ#sendMessage are now unused. I left the
signatures alone since they are public.

Does this PR introduce a breaking change?

• Yes
• No

Timing changes for anyone consuming onProcessingEndHook: the hook now fires
when the response stream completes rather than immediately before each write.
That is the same shift #17779 and #17781 made on the other paths.

Other information

Two things I did not change, both worth a separate call:

1. A rejecting handler still sends no reply. The span now closes, but the
   client waits out its own timeout with nothing on the wire. Publishing an
   error packet on that path would be the complete fix; it changes wire
   behaviour, so it should be its own PR.
2. Should the NO_MESSAGE_HANDLER path be instrumented at all? Right now it
   sits outside onProcessingStartHook on every transport. Wrapping it would
   give exporters a span for "request arrived, no handler", which seems more
   useful than the current silence — but that is a design decision, not a bug
   fix.

🤖 Generated with Claude Code