fix(mcp): cap delegated token cache TTL so a disconnect is enforced (#380)

[initializ-mk]

Addresses #380 (bounds the window; instant-revoke signal is the documented follow-up there).

Problem

After a user disconnects a delegated MCP account, the agent keeps acting as that user for up to the access-token lifetime (~1h for Atlassian). A new execution kept returning Jira results well after the account was disconnected (field report).

Root cause

The managed delegated path caches the per-subject access token in an internal SubjectTokenStore with ttl = expires_in (~1h). A platform disconnect only deletes the vault grant (agent-builder DeleteUserGrant) — it has no channel to forge's in-memory cache, Evict is never called on this path, and the provider token is still valid at the provider, so nothing downstream fails. The token keeps working until its TTL lapses.

Forge fetches from the platform token endpoint, which is the grant authority (403/404 after disconnect) — it just wasn't re-asking often enough.

Fix

Cap the delegated per-subject cache at delegatedTokenMaxTTL (5m). Forge re-validates against the platform within that window, so a disconnected grant yields ErrNoToken — and with the call-time auth gate (#377) the call parks/denies — in ≤5m instead of ~1h. Self-contained; no cross-repo change; transparent to connected users (a cheap platform token re-fetch at most every ~5m per active user-mode subject). Agent-principal (platform-mode) tokens are not capped — that grant is org registration, not a per-user connection someone disconnects.

Follow-up (in #380)

Instant revocation via a platform→forge POST /mcp/revoke {subject, server} on disconnect (evict token cache + pooled connection; fan-out mirrors signalConsent), plus downstream 401/403 eviction for provider-side revocation. That's a larger cross-repo change (the managed source's store needs to be externally reachable); this PR is the self-contained bound.

Tests

TestDelegatedTokenSource_CachesCappedTTL injects a spy SubjectTokenStore and asserts the stub's 1h expires_in is clamped to the cap. go test ./mcp/... green, gofmt + golangci-lint clean.

[initializ-mk]

Reviewed against the branch source — correct, well-scoped, and the mechanism delivers what it claims. LGTM.

Scope — third in the stack

Commits confirm #381 sits on #377 → #379 → #381. mcp_tool.go (#377) and loop.go (#379) are byte-identical to those already-reviewed branches — net-new here is just platform_token.go (the cap) + platform_delegated_test.go. Same merge ordering caveat: landing #381 subsumes #377 and #379.

The cap enforces the window — traced end-to-end

Not just the clamp — the whole path:

• TokenForSubject clamps ttl to delegatedTokenMaxTTL (5m) before store.Put, so expiresAt = now + ≤5m.
• memSubjectTokenStore.Get returns the token only while now < expiresAt - skew (skew 30s), then eagerly deletes it. Effective cache lifetime ~4m30s; the next call re-fetches from the platform token endpoint (the grant authority), which 403/404s a disconnected subject → ErrNoToken → the call parks/denies via the #377 gate. The "≤5m instead of ~1h" claim holds (≈4.5m worst case).

The uncapped agent-principal claim checks out

The cap lives only on delegatedTokenSource.TokenForSubject. The agent-principal platformTokenSource is a separate struct with its own inline p.token/p.expiresAt cache — it never touches SubjectTokenStore and is genuinely uncapped. Right call: org-registration grant, not a per-user connection.

Clamp direction is safe

if ttl > delegatedTokenMaxTTL only shrinks — a short expires_in (< 5m) is left alone, and since defaultPlatformTokenTTL is also 5m the omitted-expires_in path is a no-op.

Observations (non-blocking)

1. Platform token-endpoint fetch amplification (low). Capping raises the delegated re-fetch rate for a long-lived active subject from ~1/hour to ~1 per 4.5 min (~12×). Fine if the platform token endpoint serves from its own cache; if it instead does a full upstream OAuth refresh-token exchange with the provider on every call, this multiplies upstream refresh load and could rotate refresh tokens or brush provider rate limits. Worth a one-line confirmation that the platform endpoint caches rather than round-tripping the provider each time — the one assumption the 5m value rests on.
2. Test covers only the clamp-down (nit). CachesCappedTTL asserts 3600s → 5m via a spy store — a solid regression test; it just doesn't also assert the expires_in < 5m pass-through (an obvious no-op branch).

Scoping is honest

The PR is explicit that this bounds the exposure window and that instant revocation (platform→forge POST /mcp/revoke + downstream 401/403 eviction) is the documented #380 follow-up. Appropriate to land the self-contained bound now. CI fully green.

[initializ-mk]

This is the fix and it's correct. Clamping before store.Put means memSubjectTokenStore sets expiresAt = now + ≤5m, and its skew-aware Get (now < expiresAt - 30s, then eager delete) forces a re-fetch within ~4m30s — at which point the platform endpoint 403/404s a disconnected subject into ErrNoToken and the #377 gate denies/parks. End-to-end the exposure window drops from ~1h to ≤5m as claimed.

Clamp direction is safe (only shrinks; a sub-5m expires_in passes through, and defaultPlatformTokenTTL == 5m makes the omitted-expires_in path a no-op), and the cap is correctly scoped to the delegated per-subject source only — the agent-principal platformTokenSource keeps its own uncapped cache.