Interpreter debugger: add VS Code integration, packaging, and end-to-end acceptance

Parent epic: #1400. Depends on #1401, #1402, #1403, and #1404.

## Goal

Ship and verify the interpreter DAP as a usable product: VS Code debug type/configuration/commands, client-agnostic launch documentation, packaging, and end-to-end acceptance across the complete debugger feature set.

## Work

- [ ] Contribute a dedicated VS Code debug type and configuration schema for interpreted SharpTS, clearly distinct from compiled `coreclr` debugging.
- [ ] Add launch configuration snippets and a “Debug Current File in Interpreter” command that saves the exact document, preserves project/config/reference context, and starts the packaged adapter.
- [ ] Resolve adapter executable discovery/version compatibility for development, installed extension, and separately installed tool scenarios with actionable errors.
- [ ] Map console choice, cwd, args, environment, diagnostics, stop-on-entry, Just My Code/stdlib policy, and exception filters into the DAP launch contract.
- [ ] Ensure temporary state/logs have bounded lifecycle and no source/build artifacts accumulate unexpectedly.
- [ ] Add client-agnostic `sharpts-dap` setup and example configurations for at least one non-VS-Code DAP client or the protocol harness.
- [ ] Document compiled-vs-interpreted debugger selection, capabilities, limitations, troubleshooting, security/evaluation policy, and worker/async semantics.
- [ ] Add release/package checks so the extension/tool cannot advertise the feature without shipping a compatible adapter.

## End-to-end verification

- [ ] Automated adapter/extension integration launches a real multi-file interpreted program and exercises initialize, breakpoints, configurationDone, continue, all step operations, stackTrace, scopes, variables, evaluate, exception filters, output, termination, and disconnect.
- [ ] The scenario includes a function, class method, loop, conditional, try/catch/finally, closure, import, async function after `await`, generator after `yield`, timer/promise callback, and worker if supported by #1404.
- [ ] Breakpoints bind in entry/imported source, brace/comment lines move predictably, and source shown by the client matches the saved file.
- [ ] Dirty-file behavior is explicit and tested; stale/changed source cannot silently bind to incorrect locations.
- [ ] Manual VS Code checklist validates UI behavior: verified breakpoints, call stack, scope grouping, watch/hover/repl evaluation, exception presentation, async stepping, restart, stop, and closing the client while paused.
- [ ] At least one non-VS-Code DAP client or raw protocol harness completes the documented launch and breakpoint flow.
- [ ] Windows, Linux, and macOS packaging/launch smoke tests run where the product supports those platforms.
- [ ] Extension compile/package, adapter tool pack/install, full unit/integration, interpreter conformance, Test262, and TypeScript conformance validation is green.
- [ ] Record debug-on and debug-off startup time, stepping latency, memory, and package-size impact against documented acceptance bounds.

## Success criteria

A released SharpTS installation provides a discoverable, version-compatible interpreter debugger that launches from VS Code and a client-agnostic DAP path, passes the full source/async/inspection scenario, shuts down cleanly, and has complete user-facing configuration and limitation documentation.

## Non-goals

- Replacing compiled `coreclr` debugging.
- Requiring the C# extension for interpreter mode.
- Editor-specific behavior inside the interpreter core.

Start by reviewing parent issue #1400 and the prerequisite issues #1401 through #1404 to understand the existing DAP work before tackling this release-wide integration. Verify the VS Code and client-agnostic launch flows, packaging checks, end-to-end scenario, platform smoke tests, documentation, and performance bounds; done means a compatible released interpreter debugger passes the stated acceptance criteria.

Written by the indexing model from the issue text.