A path parameter declaration inside of an operation leads to wrong api-doc

[dgiwerzew]

Describe the bug

We use in our project spring boot 3.0.2 and springdoc-openapi (springdoc-openapi-starter-webmvc-ui) 2.0.2.
Since the springdoc-openapi 2.0.1 there is a following issue: @Parameter declaration inside of @Operation leads to a wrong api-doc result.

To Reproduce
Steps to reproduce the behavior:

This declaration

 @Operation(summary = "test update book",
            parameters = {
                    @Parameter(name = "id", description = "Id of a book", in = ParameterIn.PATH, example = "1" )
            }
    )
@PutMapping(value = "/{id}", produces = MediaType.APPLICATION_JSON_VALUE, consumes = MediaType.APPLICATION_JSON_VALUE)
public BookDto updateBook(
@PathVariable long id,
@RequestBody BookEditDto bookEditDto) {
return new BookDto();
}

Leads to this api-doc result:

"parameters":[
	{
		"name": "id",
		"in": "path",
		"description": "Id of a book",
		"required": true,
		"example": 1
	},
	{
		"name": "arg0",
		"in": "path",
		"required": true,
		"schema": {
			"type": "integer",
			"format": "int64"
		}
	}
]

If a @Parameter declaration will be moved to the method definition like this

@Operation( summary = "test update book  )
@PutMapping(value = "/{id}", produces = MediaType.APPLICATION_JSON_VALUE, consumes = MediaType.APPLICATION_JSON_VALUE)
public BookDto updateBook(
@Parameter(name = "id", description = "Id of a book", in = ParameterIn.PATH, example = "1" )
@PathVariable long id,
@RequestBody BookEditDto bookEditDto) {
return new BookDto();
}

Then the api-doc result is correct:

"parameters":[
	{
		"name": "id",
		"in": "path",
		"description": "Id of a book",
		"required": true,
		"schema": {
			"type": "integer",
			"format": "int64"
		},
		"example": 1
	}
]

Expected behavior

The @Parameter declaration inside of @Operation should work in proper way.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

[bnasslahsen]

see #2028