feat: add new param path-exclusions for rule OAR060

[mels-h]

Pull request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Other (please describe):

[SebastianDT1]

Falso positivo: path-exclusions no aplica a query params referenciados via $ref

Con la exclusión por defecto (/status), un parámetro de query definido en components.parameters y referenciado solo desde un path excluido sigue siendo reportado por OAR060.

Ejemplo (v3, aplica igual a v2/v31/v32):

paths:
  /status:
    get:
      parameters:
        - $ref: '#/components/parameters/SharedRefOnly'
      responses:
        "200":
          description: OK
components:
  parameters:
    SharedRefOnly:
      in: query
      name: q
      required: true
      schema:
        type: string

Resultado actual: issue OAR060 disparado en required: true dentro de components.parameters.SharedRefOnly, aunque /status está en path-exclusions.

Causa: isExcludedPath sube por getFirstAncestor(PATH...) desde el nodo PARAMETER. Para params $ref, el AST solo visita la definición en components (una vez, no por sitio de uso), cuyo ancestro nunca es un PATH — es components. Por eso la exclusión nunca aplica a ningún query param definido via $ref, sin importar en qué path se use.

Comparando con reglas hermanas que ya implementan path-exclusions (OAR033, OAR053, OAR029): esas subscriben al nodo PATH y bajan a operaciones/params (top-down), por eso ahí sí funciona con $ref. OAR060 usa el patrón inverso (subscribe a PARAMETER, sube ancestros), lo que introduce este gap.

No está cubierto por el fixture edge-params.yaml (que solo prueba $ref sin excluir path). Sugerencia: si el param es un $ref, resolver el path de uso real (o replicar el patrón top-down de OAR033/OAR053) antes de evaluar la exclusión.