Mock server fails to decode URL-encoded parameters before regex validation

Describe the bug
The mock server from Redocly does not decode URL-encoded query parameters (e.g., %3A for :) before applying the regular expression validation. As a result, when a query parameter contains special characters like :, the server fails validation because it compares the URL-encoded value (e.g., eip155%3A1) instead of the decoded value (e.g., eip155:1).

Expected behavior
The mock server should decode URL-encoded query parameters before applying the regular expression validation. This ensures that query parameters such as eip155:1 pass validation when checked against the regular expression pattern ^[a-z0-9]{3,8}:[-_a-zA-Z0-9]{1,32}$.

Minimal reproducible OpenAPI snippet

openapi: 3.0.0
info:
  title: Simple API with Query Parameter Validation
  version: 1.0.0
paths:
  /example:
    get:
      summary: Example endpoint with query parameter validation
      parameters:
        - name: chain_id
          in: query
          description: A query parameter representing the blockchain identifier.
          required: true
          schema:
            type: string
            pattern: "^[a-z0-9]{3,8}:[-_a-zA-Z0-9]{1,32}$"
          example: "eip155:1"
      responses:
        '200':
          description: Success
          content:
            application/json:
              schema:
                type: object
                properties:
                  message:
                    type: string
                example:
                  message: "Valid chain_id received"
        '400':
          description: Bad Request (if the `chain_id` doesn't match the pattern)
          content:
            application/json:
              schema:
                type: object
                properties:
                  error:
                    type: string
                example:
                  error: "Invalid chain_id format"

Screenshots

Additional context
Currently, when the chain_id parameter contains URL-encoded characters (e.g., eip155%3A1), the mock server does not decode these characters before validation. As a result, the regular expression validation fails. However, if the regular expression is modified to include the encoded form (%3A), like pattern: "^[a-z0-9]{3,8}(%3A)[-_a-zA-Z0-9]{1,32}$", validation passes successfully. This workaround is not ideal, as the server should decode URL parameters before applying the validation pattern.

This behavior contradicts standard URL parameter handling, where parameters are typically decoded before validation or processing. It would be beneficial if the mock server adhered to this common practice and decoded URL-encoded values prior to validation.

Start at the mock server's query-parameter parsing and validation path, using the minimal OpenAPI snippet and encoded chain_id value from the report to reproduce the failure. Done means the decoded eip155:1 value is used for regex validation while invalid values still fail.