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

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

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

Start with the step_into and step_out entry points and reproduce the reported sequence in a .NET console app, comparing currentLine and currentLineContent with get_variables_values. Done means both tools report the debugger's actual post-step location, while step_over continues to report the next line correctly.