Fix paused debug status and pause/step hangs; bump extension to 2.4.1

[Oz Zafar (ozzafar)]

Summary

• Track standard DAP stopped/continued events per session and thread, independently of whether the adapter provides source or stack frames.
• Make pause_execution idempotent for an already-stopped target; running targets still receive pause and wait for stopped/terminated state.
• Discard frame/source snapshots that span execution transitions, and keep the standalone executor's explicit state consistent.
• Complete steps on fresh stopped events even when frame IDs/locations are unchanged or no stack is available, in both VS Code and the CLI.
• Bump the VS Code extension from 2.4.0 to 2.4.1, updating the root lockfile, README badge, and dated changelog. The standalone npm package remains 0.1.1.

Fixes #157. Related source-less-frame work: #149 (not merged or closed by this PR).

Root cause

Paused detection previously depended on readable source location, and pause reused navigation logic that waited for a different snapshot even when the target was already stopped. Merely switching to frame/thread IDs is insufficient: Cortex-Debug can emit stopped followed by a successful empty stackTrace response. Its upstream stack-query error path preserves that empty response while stopped: implementation.

The new read-only observer keeps execution state separate from frame availability. It handles thread-specific/all-thread transitions, clears session state on termination, and suppresses stale UI frames after continued events. Sessions predating observation retain a frame-context fallback; a bare selected thread is not treated as proof of a stop. Startup readiness still requires actionable frame context (or the existing attach success condition), and no frame identifiers or source data are invented.

Reproduction and validation

• 175 targeted tests pass, covering state snapshots, observer lifecycle/session isolation/thread semantics, status and pause, navigation, startup dispatch, CLI execution, and Cortex-Debug inspection.
• npm run compile, targeted ESLint, and npm run package pass.
• 15 live scenarios pass in an isolated VS Code 1.134.0 window through the real MCP/router/control-server/debugger path.

Scenario	Before	After
Real Node breakpoint with frame/thread ID 0 and unavailable local source	Reported running; redundant pause consumed its timeout	MCP reports paused in 43 ms; repeated pauses return in 36/38 ms without issuing DAP pause
Cortex-style adapter: stopped event, successful empty stack, no active stack item	Reported running after a 1-second wait; pause remained pending until manual Step Into	Reports paused in 24 ms with frameId null; no redundant pause request and no manual step required
Running real Node process	Control case	Continue reports running; pause sends one DAP request and reports stopped; frame inspection becomes available when VS Code publishes the frame

The empty-stack case uses a controlled inline DAP adapter matching the verified Cortex-Debug response sequence, not physical microcontroller hardware. This reproduces the reported status/pause/manual-step behavior but does not establish the reporter's exact underlying GDB failure.

Step-over follow-up

The reporter's follow-up described step_over remaining pending until manual Step Into. We reproduced this through real VS Code/MCP with a controlled DAP adapter: a completed step emitted a fresh stopped event but kept the same source/frame metadata, or continued to have no usable source/stack. Navigation compared snapshots rather than recognizing that new stop.

The fix carries an internal stopped-event sequence into both executors' snapshots. A fresh stop completes stepping independently of frame/source availability; a resume or UI-only change does not. Selected-thread sequences are unaffected by other threads' partial transitions. Unobserved sessions retain the compatibility fallback, and no new field is exposed in tool JSON.

Follow-up scenario	Before this update	After
Same frame ID and source location	Still pending after the completed stop; manual Step Into released it	Returns in 95 ms without intervention
Source-less / empty stack	Same pending-call symptom	Returns in 69 / 75 ms without intervention
Same frame/location, no manual intervention	Consumed the configured 5-second timeout (5,045 ms)	Returns in 79 ms

Added regressions cover step-over/into/out, stops without a preceding continued event, unchanged and missing context, thread scope, snapshot lifecycle, running transitions, termination, and the CLI's real DAP request/event path. The original seven live status/pause scenarios still pass, alongside eight follow-up scenarios including repeated real Node steps and restart controls.

This is an isolated controlled-adapter reproduction, not physical microcontroller hardware. The separate restart hang was not reproduced and is not claimed fixed by this update.

Integration and scope

• Fetched and merged current origin/main into this branch; it was already up to date at 63386060586e2c887a89bab26f9d6ada49a960cd.
• Other open reports about source-line accuracy (step_into/step_out report incorrect currentLine and currentLineContent #82), stepping into methods (step_into silently degrades to step_over after any step-triggered stop — stackTrace not requested on reason: "step" stopped events #71), and breakpoints not firing (Breakpoints set via MCP API don't pause execution (using custom stdio proxy) #123) are not established as fixed and are left open.
• This PR is for maintainer review. It does not publish the extension or merge itself.

[github-actions]

✅ Extension Build Successful!

📦 VSIX artifact is ready for download

👉 View artifacts

Scroll down to the "Artifacts" section and download extension-vsix

To install: In VS Code, run Extensions: Install from VSIX... and select the downloaded file.