fix(plugin): avoid duplicate keys when auto-generating @ApiOperation

[yogeshwaran-c]

What kind of change does this PR introduce?

Bug fix (plugin / transformer).

What is the current behavior?

When introspectComments is enabled and the user has already supplied summary (or description, depending on controllerKeyOfComment) on an explicit @ApiOperation({...}), the plugin still unshifts an auto-generated key, producing a duplicate-key object literal.

Minimal repro controller:

/** doc-summary */
@ApiOperation({ summary: 'user-summary' })
@Get()
findOne() {}

Transpiles to:

openapi.ApiOperation({ summary: \"doc-summary\", summary: 'user-summary' })

Runtime behaviour happens to be correct (JS picks the last duplicate key) but:

1. the emitted JS is a duplicate-key object literal, which linters flag in strict mode;
2. it is inconsistent with how the plugin already guards description (via hasRemarksKey) and deprecated (via hasDeprecatedKey) against the exact same scenario.

What is the new behavior?

The unshift only runs when the explicit @ApiOperation({...}) argument does not already contain the generated key. So the same input now produces:

openapi.ApiOperation({ summary: 'user-summary' })

All other cases are unchanged: empty @ApiOperation({}), missing decorator, @remarks blocks, and mixed summary + description combinations still work exactly as before.

Additional context

Added a new fixture test/plugin/fixtures/app.controller-api-operation-dedupe.ts and a corresponding test in controller-class-visitor.spec.ts covering both the plain and the @remarks-combined cases. The existing appControllerTextTranspiled snapshot is untouched because none of its methods override the generated key.

[kamilmysliwiec]

could you resolve conflicts?

[yogeshwaran-c]

Conflicts resolved (rebased onto master). CI re-running.

[kamilmysliwiec]

lgtm