fix(launch): name armed logpoints instead of saying "no breakpoints" (#865)

[debugmcpdev]

What

A start_debugging launch whose only armed instrument is a logpoint answered "nothing is armed to stop it (no breakpoints, no entry stop, no caught-exception filter)". Both halves are true — a logpoint never stops the program — but "no breakpoints" reads as "your logpoint was not registered", the first thing a caller checks when a logpoint seems silent (#850 was found by exactly that doubt). The same wording shaped wait_for_stop's pending answer (#865).

How

• describeLaunchArming already saw logpoints the adapter runs on and dropped them. It now counts them (logpoints) and words them (loggingSummary: "1 logpoint(s) that log without stopping") apart from the armed summary — armed/summary keep their meaning, and logpoints downgraded to pausing breakpoints (no supportsLogPoints) are still armed as before.
• ErrorMessages.launchStillRunning(armedSummary, debuggerOffWhy, loggingSummary?) and waitForStopPending(…, { loggingSummary }) splice the clause in: "The program is running; 1 logpoint(s) that log without stopping is armed (read get_output for the messages), and nothing is armed to stop it (no pausing breakpoints, no entry stop, no caught-exception filter): …". With breakpoints as well, both are named. The wording without logpoints is untouched (the established lowercase "nothing is armed to stop it" phrase is kept, so existing tests and docs/tool-reference.md quotes still match).
• debug-launcher.ts and execution-controller.ts pass the clause through; the tool reference documents the new sentence.

Verified

• Dev server, JavaScript, a logpoint on a ticking script, start_debugging → the new sentence; get_output shows the logpoint firing.
• mcp-debugger debugging itself: the dev server launched dist/index.js http --port 0 under the JavaScript adapter with a breakpoint inside describeLaunchArming (dist/session/launch/launch-arming.js:20); an MCP client drove the nested server through the same recipe. At the breakpoint, get_local_variables read lineBreakpoints: 0, logpoints: 1, logpointsThatPause: 0, logpointsRunOn: true; evaluate_expression showed the stored logpoint verified: true and the stack describeLaunchArming ← DebugLauncher.launch ← InFlightGuard.run. After continue_execution, the inner start_debugging (held 45 s by the pause) answered with the new wording, and the nested server kept running.
• Tests: launch-arming.test.ts (counts, loggingSummary, alongside breakpoints, downgraded logpoints stay armed), error-messages.test.ts (three wording cases), session-manager-launch-contract.test.ts (logpoint-only launch answers pending: true naming the logpoint, no "(no breakpoints,"). npm run typecheck:all, npm run lint, node scripts/check-docs.mjs, session/utils/server unit suites green.

Side finding filed while doing this: #871 (JavaScript attach_to_process silently drops processId).

Fixes #865

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!