fix(decorators): forward all OpenAPI parameter fields in @ApiHeader

[yogeshwaran-c]

What kind of change does this PR introduce?

Bug fix.

What is the current behavior?

@ApiHeader only forwarded description, required, examples and schema onto the generated parameter metadata. The remaining OpenAPI Parameter Object fields it advertises via ApiHeaderOptions extends Omit<ParameterObject, 'in'> — deprecated, allowEmptyValue, style, explode, allowReserved, content — were silently dropped.

Minimal repro:

@ApiHeader({
  name: 'X-API-Version',
  deprecated: true,
  allowEmptyValue: true,
  style: 'simple',
  explode: false,
  allowReserved: true,
})
@Get()
find() {}

None of the flagged flags appear on the emitted parameter. A content-only header additionally ended up with an unwanted synthetic schema: { type: 'string' }, which is invalid per OpenAPI (schema and content are mutually exclusive on a Parameter Object).

What is the new behavior?

• All fields defined on BaseParameterObject (deprecated, allowEmptyValue, style, explode, allowReserved, content) are now forwarded into the parameter metadata.
• When the caller supplies content, the default schema: { type: 'string' } is suppressed so the emitted parameter only carries content, matching the spec's mutual-exclusivity rule.
• Behaviour for existing callers is unchanged: the default schema: { type: 'string' } and the top-level example mapping to schema.example both still apply when no content is provided.

Additional context

Added a dedicated test/decorators/api-header.decorator.spec.ts with four regressions (simple header, fully-populated header, content-only header, top-level example). The existing swagger-explorer when headers are defined suite continues to pass untouched.

[kamilmysliwiec]

LGTM