Fix WinApp debugger: complete DAP handshake so startDebugging returns true (#40)

[chiaramooney]

Summary

Fixes #40 — the WinApp debugger's vscode.debug.startDebugging(...) (and F5) returned false even when the app launched and the debugger attached successfully.

Root cause

The winapp debug type is a two-tier session:

1. F5 starts the parent winapp session.
2. WinAppDebugAdapterFactory.createDebugAdapterDescriptor does the real work — spawns winapp run --json, then starts a child coreclr/node attach session — and finally returns a NoOpDebugAdapter for the parent.

The parent's NoOpDebugAdapter only responded to the initialize and disconnect DAP requests. It never fired the initialized event and never acknowledged the launch/attach or configurationDone requests. VS Code keys startDebugging's truthy result on the parent session completing its launch handshake, so the missing launch response made VS Code treat the session as failed-to-start → startDebugging resolved false, even though the app was already running (all real work happens before the no-op adapter is returned).

So it wasn't an early-return/timing bug as the issue speculated — it's an incomplete DAP handshake in the no-op parent adapter.

Fix

Complete the handshake in NoOpDebugAdapter:

• respond to initialize advertising supportsConfigurationDoneRequest, then fire the initialized event
• acknowledge launch/attach (the response startDebugging keys its result on)
• acknowledge configurationDone
• acknowledge any other request so VS Code never blocks
• use a proper monotonic outgoing seq counter instead of seq: 0

No change to how the app is launched or the child debugger attaches.

Testing

• npm run compile-tsc — clean
• npm run lint — 0 errors (pre-existing warnings unrelated to this change)
• npm run package (esbuild production) — build complete
• npm run test:unit — 592 passing, 0 failing