VICE backend: ExecuteJsr doesn't wait for execution to stop at breakpoint

[barryw]

Summary

When the VICE backend executes a JSR, it calls vice.execution.run and immediately reads memory/registers without waiting for the execution to actually stop at the RTS return breakpoint. This causes incorrect test results because the code hasn't finished running yet.

Evidence

Trace output shows the sequence:

MCP request: vice.execution.run (id=13)        ← resume execution
MCP request: vice.registers.get (id=14)         ← immediately reads registers
MCP request: vice.memory.read (id=15)           ← reads memory before code finishes

There is no polling of execution state between execution.run and the subsequent reads.

Expected Behavior

After vice.execution.run, the backend should poll vice.registers.get (checking PC) or wait for VICE to report that execution stopped at the breakpoint. The flow should be:

1. Set breakpoint at return address
2. vice.execution.run
3. Poll loop: vice.registers.get until PC equals the breakpoint address (or a timeout)
4. Read memory/registers for assertions

Additional Issue

The breakpoint at address $0000 also causes the VICE monitor to pop up (interactive debugger), which blocks the emulator. Consider using stop: false breakpoints and polling PC instead, or using vice.run_until instead of breakpoints.

Impact

This affects all JSR-based tests on the VICE backend. Simple tests like EnableBook/DisableBook happen to pass because they're fast enough, but anything substantial (TTClear, TTStore) fails because the code hasn't finished executing when assertions run.