feat(swagger): warn when @ApiTags receives hierarchy fields

[frbuceta]

PR Type

• Feature
• Bug fix
• Other

What is the current behavior?

@ApiTags accepts the object form { name, parent, kind } (added in #3725, released in v11.4.0), but it normalizes every entry to its name, silently discarding parent and kind:

const normalizedTags = tags.map((tag) =>
  typeof tag === 'string' ? tag : tag.name
);

The decorator-level hierarchy metadata never reaches document.tags, so the OpenAPI 3.2 tag hierarchy is lost with no feedback to the user. Root-level tag hierarchy is only honored when declared via DocumentBuilder.addTag(name, description, { parent, kind }).

Issue: #3922

What is the new behavior?

When parent or kind is set on an @ApiTags object argument, the decorator now emits a runtime warning that points users to DocumentBuilder.addTag() — the supported way to define a root-level tag hierarchy.

[ApiTags] Tag "Sessions" was declared with hierarchy fields (parent/kind) on
@ApiTags, which are dropped. Define them via DocumentBuilder.addTag("Sessions",
description, { parent, kind }) so they reach the root-level tags of the document.

This implements the resolution agreed in #3922 ("Reject / warn"). String arguments and object arguments that only carry name are unaffected — no warning is emitted.

Does this PR introduce a breaking change?

• Yes
• No

Tag normalization is unchanged; only a diagnostic warning is added.

Other information

Closes #3922. Tests added for the warn / no-warn cases in test/decorators/api-use-tags.decorator.spec.ts.