`step_into`/`step_out` report incorrect `currentLine` and `currentLineContent`

[mikejohnstonPremierinc]

Description

The step_into and step_out tools report stale or incorrect values for currentLine and currentLineContent in their responses. The reported position does not match where the debugger actually stopped.

Steps to Reproduce

1. Set a breakpoint on a line that calls a method (e.g., line 21: int result = Add(a, b);)
2. Start debugging a .NET console app via start_debugging
3. Hit the breakpoint (confirmed at line 21)
4. Call step_into

Expected: Response shows currentLine pointing to the first line inside the Add() method (e.g., line 8: return x + y;)

Actual: Response shows currentLine: 21 (the call site, not the stepped-into location). However, get_variables_values correctly shows the parameters of Add() (x, y), confirming the debugger DID step into the method.

Observed Pattern

Tool	Position Reported	Variables Reported	Actual Location
step_into	Call site (stale)	Correct (target method params)	Inside target method
step_out	Inside method (stale)	Correct (caller's locals)	Back in caller
step_over	Usually correct	Correct	Next line

The position appears to be "one step behind" - reporting where the debugger WAS, not where it IS after the step completed.

Workaround

Always call get_variables_values after stepping to determine the true execution state. The variables are always accurate and reflect the actual paused location.

Impact

AI agents that rely on currentLine to build a mental model of execution flow will have an incorrect picture, potentially leading to confused reasoning about program state.

Environment

• DebugMCP v1.1.4
• .NET 9.0 console app (coreclr)
• VS Code stable (latest)
• C# extension: ms-dotnettools.csharp-2.140.8-win32-x64