`deck gateway validate` fails with unknown field `config.client_jwk[0].false` when OIDC client_jwk contains an unquoted n key

Description

When validating a decK YAML file that contains an OpenID Connect plugin configuration with client_jwk, deck gateway validate --verbose 9 fails with the following error:

{
  "code": 3,
  "details": [
    {
      "@type": "type.googleapis.com/kong.admin.model.v1.ErrorDetail",
      "field": "config.client_jwk[0].false",
      "messages": ["unknown field"],
      "type": "ERROR_TYPE_FIELD"
    }
  ],
  "message": "validation error: unknown field"
}

The original YAML does not contain a false field.
It contains a JWK field named n, which is a standard RSA JWK parameter representing the modulus.

It looks like the YAML parser interprets the unquoted key n as the boolean value false, resulting in the field being sent or validated as:

false: <modulus value>

instead of:

n: <modulus value>

This is problematic because n is a valid JWK field and is required for RSA keys.

Minimal example

_format_version: "3.0"

plugins:
  - name: openid-connect
    config:
      client_id:
        - example-client
      client_jwk:
        - kty: RSA
          alg: RS256
          kid: example-key
          e: AQAB
          n: example-modulus-value

Actual behavior

Validation fails with:

{
  "field": "config.client_jwk[0].false",
  "messages": ["unknown field"]
}

Expected behavior

n should be treated as a string key, not as a boolean false.

The following should validate as a normal JWK field:

n: example-modulus-value

Alternatively, if decK requires quoting for YAML 1.1 compatibility, the error message should clearly indicate that the n key was interpreted as a boolean key and suggest quoting it:

"n": example-modulus-value

Workaround

Quoting the n field avoids the issue:

client_jwk:
  - kty: RSA
    alg: RS256
    kid: example-key
    e: AQAB
    "n": example-modulus-value

The y field should probably also be quoted for the same reason, since it may be interpreted as boolean true by YAML 1.1 parsers:

"y": null

It may also be safer to quote fields containing special characters, such as:

"x5t#S256": null

Why this matters

JWK uses short field names such as n, e, x, and y.
In particular, RSA JWKs commonly include n and e.

If decK accepts YAML as input for Kong configuration, JWK field names should be handled safely, or decK should provide a clearer validation error when YAML boolean key coercion occurs.

Environment

• decK version: 1.64
• Command: deck gateway validate kong.yaml
• Plugin: openid-connect
• Field: config.client_jwk

Start with the deck gateway validate entry point and reproduce the failure using the minimal YAML in the issue, focusing on how the client_jwk keys are parsed and validated. Done means an unquoted n is handled as the JWK field rather than reported as false, with a regression test covering the example.