Java: launch path serves a stale JDI bridge .class — the staleness guard exists but is unreachable

[debugmcpdev]

packages/adapter-java/src/java-debug-adapter.ts:218-222 resolves the JDI bridge like this:

let bridgeDir = resolveJdiBridgeClassDir();
if (!bridgeDir) {
  bridgeDir = ensureJdiBridgeCompiled();
}

resolveJdiBridgeClassDir (utils/jdi-resolver.ts:20-53) is a pure existsSync(JdiDapServer.class) walk with no staleness check. ensureJdiBridgeCompiled (jdi-resolver.ts:89-138) does carry an mtime guard (isClassStale) — with a comment explicitly about stale bridges dropping newly-added launch args — but the guard is unreachable from the launch path: buildAdapterCommand only calls it when the resolver already returned null, i.e. when no .class exists at all, so there is never anything to be stale.

validateEnvironment (java-debug-adapter.ts:165-172) has the same shape: resolve-only, warn if missing, never compile.

Consequence: edit JdiDapServer.java, start a debug session, and the old compiled bridge is served silently — new launch keys are dropped, new DAP behavior is absent, and nothing says why. I hit this while fixing #642 (the bridge-side cwd/env support): without a manual pnpm --filter @debugmcp/adapter-java run build:adapter, the freshly-edited bridge source has no effect. The build script's own mtime check (scripts/compile-jdi-bridge.js:58-65) is correct — but only runs on build:adapter, not at session time.

Fix shape: make the launch path staleness-aware — e.g. buildAdapterCommand calls ensureJdiBridgeCompiled() unconditionally when the source file is resolvable (it already early-returns on a fresh class, so the cost is one pair of stats), or resolveJdiBridgeClassDir learns to reject a class older than its adjacent source. Either way the existing isClassStale logic is the right primitive; it just needs to be reachable.

Found while working #642, whose PR ships the bridge fix that made the stale-class serving visible.

[debugmcpdev]

Confirmed live while finishing the #642 fix. After editing JdiDapServer.java, git checkout between branches rewrote the file's mtime; a fresh start_debugging then ran an old compiled bridge — the DAP launch trace showed cwd correctly present in the request args, but the debuggee reported the server's user.dir, i.e. the bridge received the key and ignored it (the pre-#642 behavior). rm -rf packages/adapter-java/java/out && pnpm --filter @debugmcp/adapter-java run build:adapter fixed it and both cwd/env e2e tests passed. So the launch path genuinely serves a stale .class — exactly this issue. Local-iteration only (CI compiles the bridge fresh on every run), but it's a real foot-gun for anyone editing the bridge.