[BUG] Unbeatable scenario setup

[GotFlojo]

Bug Description

Some of the scenarios set you up in a way that makes them unbeatable in "optimal movements".
The basic movement scenarios for j and k have the cursor not only vertically displaced but also one character horizontally. The optimal solution says 1, which would only work without the horizontal offset.

Steps to Reproduce

1. Go to scenario "Move cursor up using 'k' " or "Move cursor down using 'j'"
2. Try to solve with optimal movement (expected: 1)

Expected Behavior

Initial Scenario setup should make it possible to solve with suggested optimal movement

Actual Behavior

Initial Scenario setup prevents suggested optimal solution.

Screenshots

Notice the horizontal offset of current cursor and target cursor in each of these scenarios.
This is the initial setup. No keys have been pressed yet.
A solution with 1 key press is impossible to achieve with this setup.

Environment

• OS: [ Windows 11]
• Terminal: [Windows Terminal]
• Rust version: [output of rustc --version]
• Helix Trainer version: helix-trainer-v0.5.9-x86_64-pc-windows-msvc from the Releases page

Additional Context

Logs

[GotFlojo]

Same offset errors in the multiline j ; k scenarios. Except there it is even more extreme

It is possible to solve this with two movements but the solution is not what is expected.

There is something wrong with the scenario setup.

[bug-ops]

Tested on macOS (v0.5.9, post-PR #183): scenarios 'Move down one line' (j) and 'Move up one line' (k) both score Perfect with 1 action. TOML data is correct: setup cursor=[1,8] → target=[2,8] for j, same column both sides.

Unable to reproduce on macOS. The issue appears to be Windows Terminal-specific rendering — the cursor is displayed at a visually different position than the simulator's internal position. The simulator uses helix_core::movement::move_vertically with TextFormat::default() (soft_wrap=false, tab_width=4) which should be platform-independent for ASCII content.

Possible causes to investigate on Windows:

1. Windows Terminal cursor rendering offset (ANSI escape code handling difference)
2. Crossterm's cursor positioning behavior on Windows vs macOS

The actual game logic (scoring) works correctly — only the visual cursor display in the Current/Target panels may be misaligned on Windows Terminal. If you can confirm whether pressing 'j' actually scores Perfect (even if the display looks wrong), that would help narrow down if this is a rendering bug vs logic bug.