Verified JS breakpoints keep the raw provisional message 'breakpoint.provisionalBreakpoint' (untranslated key + contradicts verified:true)

[debugmcpdev]

Summary

A JavaScript breakpoint that has successfully bound still carries the provisional (pre-bind) message from js-debug, and that message is an untranslated l10n key. list_breakpoints ends up asserting two contradictory things at once:

{
  "id": "0bbdc056-…",
  "file": ".../examples/javascript/simple_test.js",
  "line": 11,
  "logMessage": "LOGPOINT a={a}",
  "verified": true,                              // ← bound
  "adapterId": 1,                                // ← bound
  "message": "breakpoint.provisionalBreakpoint"  // ← upstream text for this key is "Unbound breakpoint"
}

Two separate problems:

1. Stale state (ours). The provisional message is never cleared once the breakpoint verifies. verified: true + adapterId: 1 alongside a message meaning "Unbound breakpoint" is self-contradictory, and message is exactly the field an agent reads to find out why a breakpoint is in a given state.
2. Raw i18n key (upstream, but we ship it). The string is a bundle key, not human text. In the vendored vsDebugServer.js, js-debug's pending-target stub answers setBreakpoints with message: l10n.t("breakpoint.provisionalBreakpoint", "Unbound breakpoint"), and since L10N_FSPATH_TO_BUNDLE is unset in our spawn the key is returned verbatim rather than the fallback.

Reproduction (v0.24.2)

create_debug_session { language: "javascript" }
set_breakpoint { file: "examples/javascript/simple_test.js", line: 11,
                 logMessage: "LOGPOINT a={a}" }
start_debugging { scriptPath: "examples/javascript/simple_test.js",
                  dapLaunchArgs: { stopOnEntry: false } }
list_breakpoints { }
→ the record above

Reproduced on all three build groups (local, npx, docker) during a full /testdebugger sweep, then confirmed by hand. Plain line breakpoints show it too — it is not logpoint-specific.

Severity

Low / cosmetic in isolation — verified and adapterId are correct, so nothing is functionally broken. Filing it because it is cheap to fix and it actively degrades the one free-text field an agent uses to diagnose breakpoint state: right now that field says "unbound" about a bound breakpoint, in a form no human or model can interpret.

Suggested fix

Clear (or replace) the provisional message when the breakpoint transitions to verified: true — the same reconciliation path #439 added for forwarding the worker's initial setBreakpoints results would be the natural place. Optionally also map known js-debug l10n keys to their English fallbacks before surfacing them, so any other key that leaks reads as text.

Good first issue: small, well-isolated, easy to assert in a test (list_breakpoints on a verified JS breakpoint must not contain a breakpoint. key).