feat(auth): name the path that granted access, and stop blaming the caller

Closes #1. Closes gitea-mcp#58. Closes gitea-mcp#60.

Three small changes to one decision point, kept together because they are the
same surface and the same incident.

1. A JWT IS NEVER A STATIC-TOKEN MISMATCH (gitea-mcp#58)

The fall-through reason was chosen by which comparison ran last, not by what the
caller presented. So a JWT against a server with no JWT auth configured logged:

    reason=static_token_mismatch  token_type=jwt  status=401

The two fields contradict each other, and the sentence reads as "you presented
the wrong token" when the truth is "this server could not have accepted any
token of that kind". The misdirection reached the user — claude.ai surfaces
"Authorization with gitea failed. You can check your credentials and
permissions." — and a debugging session went into re-running the OAuth flow
while the credentials were valid throughout.

Now `jwt_auth_not_configured` for a JWT; `static_token_mismatch` stays, and is
asserted to stay, for an actual static-token mismatch. Fixing the misleading
case must not delete the accurate one.

Note this is now the ONLY way to reach that branch with a JWT: since v0.6.0 a
validator that merely could not reach its issuer is non-nil and answers
ErrUnavailable -> 503. A nil validator means the server was never given an
issuer.

2. SUCCESS IS LOGGED, WITH THE PATH THAT GRANTED IT (gitea-mcp#60)

The middleware logged only on rejection. After re-authing a connector there was
no way to tell whether a request used the static token or a JWT, only inference
from which failures were absent. A log that proves a request failed, and nothing
about how the successful ones succeeded, cannot answer the question anyone
actually has during an auth incident.

    INFO mcp auth accepted auth_path=jwt caller=alice token_fp=... remote=...
    INFO mcp auth accepted auth_path=static token_fp=... remote=...

Same disclosure rules as deny: a fingerprint, never the credential. The JWT
subject is included because distinguishing WHO is the point of that path;
`caller` is omitted rather than empty for the static path, which has no identity
to report.

3. JWKS REFRESH INTERVAL IS CONFIGURABLE (#1)

It was hardcoded at 1h, so an issuer rotating its signing key could leave every
consumer rejecting valid JWTs for up to an hour. WithRefreshInterval, defaulting
to 1h so nothing changes for existing callers.

Variadic, per #1's own preferred option — a new positional parameter would force
a coordinated bump across every consumer. Deliberately NOT read from the
environment inside the library: a shared lib calling os.Getenv is a hidden
dependency that surprises its consumers. Config ownership stays at the edge.

The effective value is logged when an issuer resolves, which is #1's second
acceptance criterion and the thing an operator needs during a key-rotation
incident. The test asserts the configured value reaches the registration site
via that line — a silently-ignored option being the failure mode worth pinning.
Whether jwx then honours it is jwx's to test.

One of my own assertions was wrong and the test caught it: tokenType() says
"opaque", not "static", for a non-JWT credential. Corrected to the existing
vocabulary rather than changing the vocabulary to match a new test.

Verified: golangci-lint 0 issues; go vet clean; go test -race -count=1 ok.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

auth/jwt_bootrace_test.go

@@ -4,6 +4,7 @@ import (
 	"context"
 	"errors"
 	"testing"
+	"time"
 
 	"github.com/stretchr/testify/require"
 )
@@ -113,3 +114,42 @@ func TestJWTValidator_UnresolvableIssuer_IsUnavailableAndNotReady(t *testing.T)
 	require.False(t, ready)
 	require.Error(t, why)
 }
+
+// mcp-chassis#1: the JWKS min-refresh interval was hardcoded at 1h, so a signing
+// key rotation could leave every consumer rejecting valid JWTs for up to an hour.
+//
+// The interval reaching jwx's cache is not observable from outside jwx, and
+// testing jwx's own refresh behaviour is jwx's job. What IS this package's job,
+// and what this asserts, is that the configured value reaches the registration
+// site and is stated in the log — which is also #1's second acceptance criterion
+// ("effective value logged at init"). A silently-ignored option is the failure
+// mode worth pinning.
+func TestWithRefreshInterval_ReachesRegistrationAndIsLogged(t *testing.T) {
+	for _, tc := range []struct {
+		name string
+		opts []Option
+		want string
+	}{
+		{name: "default is 1h, unchanged", want: "1h0m0s"},
+		{name: "override", opts: []Option{WithRefreshInterval(5 * time.Minute)}, want: "5m0s"},
+	} {
+		t.Run(tc.name, func(t *testing.T) {
+			iss := newTestIssuer(t)
+			logs := captureLogs(t)
+
+			v, err := NewMultiJWTValidator(t.Context(),
+				[]IssuerConfig{{IssuerURL: iss.url, Audience: "aud"}}, tc.opts...)
+			require.NoError(t, err)
+			require.NotNil(t, v)
+
+			var found bool
+			for _, l := range logs() {
+				if l["msg"] == "jwt issuer resolved" {
+					require.Equal(t, tc.want, l["jwks_refresh_interval"])
+					found = true
+				}
+			}
+			require.True(t, found, "resolving an issuer must state the effective refresh interval")
+		})
+	}
+}