fix(mcp): enforce MCP feature flag on all token auth paths

[hacktron-app]

Vulnerability (root cause)

McpTokenServiceCEImpl.authenticate(...) is the sink used by the MCP token authentication manager. It should reject authentication when the organization has the MCP feature disabled, but the enablement check (validateMCPEnabled()) was applied incorrectly, allowing a bypass (A07:2025):

• Cache path (authenticateFromCache) — context loss / fail-open. The check was written as:

  Mono.just(user)
      .contextWrite(ReactiveSecurityContextHolder.withAuthentication(...))
      .contextWrite(ctx -> ctx.put(ORGANIZATION_ID, user.getOrganizationId()))
      .then(validateMCPEnabled())
      .thenReturn(user);

  Reactor context propagates upstream from the subscriber; the contextWrite operators only decorate the inner Mono.just(user) and never reach validateMCPEnabled(), which runs downstream of .then(). In EE, getCurrentUserOrganizationId() reads the request context, so it resolved empty, validateMCPEnabled() emitted nothing, and the check failed open — authentication succeeded even with MCP disabled.
• Store path (authenticateFromStore) — the DB-backed fallback never called validateMCPEnabled() at all, bypassing the flag entirely.

Fix

Enforce the flag once, at the top of the public authenticate(...) method, on the caller's real reactive context, before either path runs:

return validateMCPEnabled()
        .then(authenticateFromCache(userKey, mcpKeyId)
                .switchIfEmpty(Mono.defer(() -> authenticateFromStore(userKey, mcpKeyId))));

validateMCPEnabled() errors with AppsmithException when MCP is disabled, which now propagates to the caller for both cache and store paths. The ineffective contextWrite(...)/.then(validateMCPEnabled()) block is removed from authenticateFromCache, along with the imports that became unused (ReactiveSecurityContextHolder, Authentication, UsernamePasswordAuthenticationToken, ORGANIZATION_ID).

This matches how create(...) already gates on validateMCPEnabled() and centralizes the check at the single shared entry point.

Verification

• Traced the reactive flow: with MCP enabled, getCurrentUserOrganization() emits the org, validateMCPEnabled() completes, and the cache/store flow proceeds unchanged (legitimate tokens still authenticate). With MCP disabled, validateMCPEnabled() errors before any token lookup, so both paths are blocked.
• Reviewed callers: authenticate has no EE override; authenticateFromCache/authenticateFromStore are private with no overrides, so the centralized gate covers CE and EE (McpTokenServiceImpl extends the CE impl).
• Tests: fixed the existing should_throwError_whenMCPDisabledCacheHashMatchesAndUserIsEnabled test, which asserted via expectErrorSatisfies(...) but was missing the terminal .verify() (so it never subscribed and passed vacuously — the reason the bug went unnoticed). Added should_throwError_whenMCPDisabledAndStoreHashMatchesAndUserIsEnabled covering the store path. Could not execute the suite: the sandbox has no JDK/Maven available.

---

Automated fix by Hacktron for finding: https://app.hacktron.ai/appsmith-inc/findings/1870355c-c981-48ad-b8b0-c124d304abf0