types(core): use removal-marker literal for messageTypeField error message

Per PR review: `messageTypeField?: never` produces a generic "Type
'string' is not assignable to type 'never'" diagnostic. Switch to a
removal-marker string literal so the diagnostic surfaces the migration
hint right at the offending call site, e.g. "Type 'type' is not
assignable to type '__REMOVED_USE_messageTypeResolver_INSTEAD__ |
undefined'".

Note on the `messageTypeField: undefined` loophole: closing it would
require enabling `exactOptionalPropertyTypes` package-wide, which
produces ~13 unrelated type errors in core (HandlerContainer,
MessageSchemaContainer, AbstractQueueService, startupResourcePolling)
and is a separate refactor. Passing `undefined` is operationally
identical to omitting the field, so this guard catches the realistic
regression — `messageTypeField: '<name>'`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: Igor Savin

packages/core/lib/types/queueOptionsTypes.ts

@@ -118,12 +118,17 @@ export type CommonQueueOptions = {
    * @deprecated Removed in core 25.x. Use `messageTypeResolver: { messageTypePath: '<field>' }`
    * (or `{ literal: '<type>' }` / `{ resolver: fn }`) instead. See UPGRADING.md.
    *
-   * Typed as `never` so callers that still pass it get a compile-time error rather than
-   * a silent runtime drop. Notably, leaving this set on a publisher with payload offloading
-   * causes the message `type` field to be stripped from the offloaded SNS body, which then
-   * silently fails any downstream subscription whose FilterPolicy filters on `type`.
+   * Typed as a removal-marker string literal so callers passing the legacy option get a
+   * compile-time error whose diagnostic shows the migration hint, rather than a silent
+   * runtime drop. Leaving this set on a publisher with payload offloading causes the
+   * message `type` field to be stripped from the offloaded SNS body, which then silently
+   * fails any downstream subscription whose FilterPolicy filters on `type`.
+   *
+   * Note: passing `messageTypeField: undefined` still type-checks (without
+   * `exactOptionalPropertyTypes`), but `undefined` is operationally identical to omitting
+   * the field, so this guard catches the realistic regression (`messageTypeField: '<name>'`).
    */
-  messageTypeField?: never
+  messageTypeField?: '__REMOVED_USE_messageTypeResolver_INSTEAD__'
   messageIdField?: string
   messageTimestampField?: string
   messageDeduplicationIdField?: string