AS issuer validation failure

Describe the bug
I'm currently working on implementing client-side OAuth in Go SDK and I'm running into a conformance test failure which I'm not sure is warranted, so I would like to consult.

The issue is related to Authorization Server Metadata handling. In metadata-var2 and metadata-var3 tests, the authorization server's issuer identifier contains a non-empty path component /tenant1. According to RFC 8141 section 3.3 a client must validate if the issuer value returned by the authorization server is the same as the identifier used to create the URL for the metadata. However, the AS returns a value with no path component, for example:

 {
    "id": "outgoing-auth-response",
    "name": "Outgoing-auth-response",
    "description": "Sent 200 response for GET /.well-known/oauth-authorization-server/tenant1",
    "status": "INFO",
    "timestamp": "2026-02-10T14:02:08.022Z",
    "details": {
      "method": "GET",
      "path": "/.well-known/oauth-authorization-server/tenant1",
      "statusCode": 200,
      "headers": {
        "x-powered-by": "Express",
        "content-type": "application/json; charset=utf-8",
        "content-length": "417",
        "etag": "W/\"1a1-vdDFr5xugGjES09D01A3xMuA7xw\""
      },
      "body": {
        "issuer": "http://localhost:35909",  <--- HERE
        "authorization_endpoint": "http://localhost:35909/tenant1/authorize",
        "token_endpoint": "http://localhost:35909/tenant1/token",
        "registration_endpoint": "http://localhost:35909/tenant1/register",
        "response_types_supported": [
          "code"
        ],
        "grant_types_supported": [
          "authorization_code",
          "refresh_token"
        ],
        "code_challenge_methods_supported": [
          "S256"
        ],
        "token_endpoint_auth_methods_supported": [
          "none"
        ]
      }
    }
  },

Should this behavior be adjusted?

To Reproduce
Steps to reproduce the behavior:

1. Run metadata-var2 or metadata-var3 conformance test with a working SDK and inspect checks.json.

Expected behavior
I would expect the issuer field to contain the path component used to construct the AS metadata URL.

Run the metadata-var2 or metadata-var3 conformance test and inspect checks.json, focusing on the issuer returned for the metadata URL containing /tenant1. Compare the observed issuer with the RFC 8414 validation requirement and determine whether the test expectation or authorization-server response should change. Done means the behavior and expected issuer value are resolved for these tests.