Path matching precedence bug: parameterized paths incorrectly match literal paths

[magiusdarrigo]

The OpenAPI validator incorrectly matches literal path segments against parameterized paths when the parameterized path is defined before the literal path in the spec. This causes validation failures where literal path segments are treated as path parameters and validated against parameter schemas.

Expected Behavior

According to OpenAPI specification, more specific paths (literal segments) should take precedence over parameterized paths during route matching, regardless of definition order in the spec.

Actual Behavior

In my example, the validator matches /Messages/Operations against the /Messages/{message_id} path pattern, treating "Operations" as a message_id parameter and validating it against the MessageId schema pattern.

Error Message

openapi request validation failed: Path parameter 'message_id' failed to validate (/pattern: 'Operations' does not match pattern '^comms_message_[0-7][a-hjkmnpqrstv-z0-9]{25,34}'). Fix: Ensure that the object being submitted, matches the schema correctly

Example Request

GET /Messages/Operations?start_date=2020-01-01T00:00:00Z&end_date=2025-12-31T23:59:59Z&page_size=10

Minimal Reproduction Case

openapi: 3.1.0
info:
  title: Path Precedence Bug
  version: 1.0.0
paths:
  /Messages/{message_id}:
    parameters:
      - name: message_id
        in: path
        required: true
        schema:
          type: string
          pattern: '^comms_message_[0-7][a-hjkmnpqrstv-z0-9]{25,34}'
    get:
      responses:
        '200':
          description: OK
  /Messages/Operations:
    get:
      summary: List Operations
      responses:
        '200':
          description: OK

Test: GET /Messages/Operations should match the literal path, not the parameterized one.

Versions in my go.mod github.com/pb33f/libopenapi v0.27.2 github.com/pb33f/libopenapi-validator v0.6.3