feat(microservices): add opt-in strict request envelope option

[hktitof]

PR Checklist

Please check if your PR fulfills the following requirements:

• 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 (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

the request deserializer treats any packet carrying a pattern or a data key as a native Nest packet, so a foreign payload like { type: 'alert', data: { ... } } reaches handlers unmodified and the handler silently reads the inner data while the rest of the payload is lost

the response side already rejects foreign JSON through an envelope-keys check (#17670), but the request side can't take the same treatment as a default flip bcs bare { data: X } packets are native today, as Kamil laid out when closing #17672

Issue Number: #17672, #17669

Steps to reproduce

1. take the spec files from this PR, then run git checkout master -- packages/microservices/deserializers/incoming-request.deserializer.ts and npx vitest run packages/microservices/test/deserializers/
2. Expected: a packet carrying a key outside the request envelope (id, pattern, data) counts as foreign and gets wrapped with the channel pattern
3. Actual (raw output on untouched master, the strict option is swallowed bcs it does not exist there):

FAIL  packages/microservices/test/deserializers/kafka-request.deserializer.spec.ts > KafkaRequestDeserializer > with the strictRequestEnvelope option > should forward the option to the base deserializer
AssertionError: expected { type: 'alert', data: { topic: 'logs' } } to deeply equal { pattern: 'alerts', data: { …(2) } }

 Test Files  3 failed | 3 passed (6)
      Tests  3 failed | 21 passed (24)

What is the new behavior?

IncomingRequestDeserializer accepts an options object, new IncomingRequestDeserializer({ strictRequestEnvelope: true }). with the option on, isExternal mirrors the response-side check: a packet counts as foreign when it carries any key outside the request envelope (id, pattern, data), so { type: 'alert', data: ... } gets wrapped with the channel pattern and the handler receives the full payload

with the option off (the default) nothing changes for existing users, KafkaRequestDeserializer and NatsRequestJSONDeserializer inherit the option through the base constructor, and bare { data: X } packets stay native in both modes

Does this PR introduce a breaking change?

• Yes
• No

Other information

follows the shape Kamil suggested in #17672: the same ENVELOPE_KEYS allowlist #17670 uses on the response side, shipped as an opt-in deserializer option, which keeps the two deserializers consistent

[kamilmysliwiec]

if the default is off, why do we need that need flag in the first place? if someone runs into this issue they can just:

class StrictDeserializer extends IncomingRequestDeserializer {
  isExternal(value: any) {
    if (!value || typeof value !== 'object') return true;
    const keys = Object.keys(value);
    return keys.length === 0 || keys.some(k => !['id', 'pattern', 'data'].includes(k));
  }
}

and pass their own deserializer