feat: SourcePawn remote debugger for VS Code

Debug SourcePawn plugins running on a live SourceMod server from VS Code,
over DAP: breakpoints (conditional, hit-count, logpoints and non-freezing
snapshot logpoints), call stack, variable inspection and editing, stepping,
Debug Console REPL, data breakpoints, memory view, and a function profiler.

Layout:
  dap/                  DAP/TCP/profiler crate (ours)
  sp-console-debugger/  vendored upstream, NOT committed -- reconstructed at
                        build time from patches/*.commit + *.patch
  vscode/               the VS Code extension and its test suites
  docs/                 usage, architecture, protocol, troubleshooting

Security posture: the debug port listens on 127.0.0.1 by default, since a
session can read and write plugin memory and can hold the game thread on a
breakpoint. Exposing it beyond loopback requires a shared token, which is
demanded before any request is served; without one the listener refuses to
start.

Lifecycle: the accept thread and all client threads are owned and joined on
teardown, so unloading or reloading the extension -- and restarting the server
with an editor attached -- neither freezes nor crashes the host process.

Tests: unit suites plus two integration suites driven against a mock srcds
(full DAP session, and extension load/unload/reload/shutdown), alongside the
upstream console regression harness.

Also ships the GitHub issue form and pull request template: the bug form asks
for the SourceMod line and how the extension was loaded (the two answers that
explain most reports) plus the evidence -- `sm exts list`, traced Debug Console
output, server log. The PR checklist covers what breaks quietly here:
regenerating the vendored patch, MSVC-only pitfalls, releasing threads and VM
callbacks on unload, and the docs that go stale with each.

Author: Red4Hack

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,118 @@
+name: Bug report
+description: The debugger misbehaves, fails to connect, or takes the server down
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for the report. The two details that resolve most issues fastest are
+        **which SourceMod line the server runs** and **how the extension was loaded**,
+        so please do not skip those fields.
+
+        **Never paste your `token`.** If you quote any part of
+        `console-debugger.cfg` or of your launch configuration, redact it first.
+
+  - type: checkboxes
+    id: preflight
+    attributes:
+      label: Preflight
+      description: Tick what applies. Leaving a box unticked is useful information too.
+      options:
+        - label: The server was fully restarted after deploying the extension (not `sm exts load` / `reload`)
+        - label: The server package matches the server's SourceMod line (`sm1.12` vs `sm1.13`)
+        - label: The patched SourcePawn VM from the release package is installed
+        - label: I can reproduce this with only the debugger extension and the plugin involved
+
+  - type: textarea
+    id: what-happened
+    attributes:
+      label: What happened
+      description: What you did, what you expected, and what happened instead.
+      placeholder: |
+        Set a breakpoint on line 42 of antibhop.sp and started the session.
+        Expected: the breakpoint verifies and the server stops on it.
+        Actual: the breakpoint stays hollow and `launch` fails with "...".
+    validations:
+      required: true
+
+  - type: textarea
+    id: reproduce
+    attributes:
+      label: Steps to reproduce
+      description: |
+        Smallest sequence that shows the problem. A minimal plugin helps enormously.
+        If it is a connection problem, say which host and port the editor used.
+      placeholder: |
+        1. Start the server
+        2. F5 in VS Code with a launch configuration pointing at that server
+        3. Trigger the plugin (say hello in chat)
+        4. ...
+    validations:
+      required: true
+
+  - type: dropdown
+    id: sm-line
+    attributes:
+      label: SourceMod line
+      options:
+        - "1.12 (stable)"
+        - "1.13 (dev)"
+        - Not sure
+    validations:
+      required: true
+
+  - type: input
+    id: versions
+    attributes:
+      label: Versions
+      description: Server package and `.vsix` you installed, plus the exact SourceMod build.
+      placeholder: "sp-debugger-server-linux-sm1.12 (release 1.0.3), sp-debugger.vsix 1.0.3, SourceMod 1.12.0.7246"
+    validations:
+      required: true
+
+  - type: dropdown
+    id: os
+    attributes:
+      label: Game server OS
+      options:
+        - Linux
+        - Windows
+        - Other
+    validations:
+      required: true
+
+  - type: input
+    id: game
+    attributes:
+      label: Game / engine
+      placeholder: "CS:S, TF2, L4D2, ..."
+
+  - type: textarea
+    id: extension-state
+    attributes:
+      label: "`sm exts list` output"
+      description: Run it in the server console. It shows whether the debugger loaded at all.
+      render: text
+      placeholder: |
+        [01] Automatic Updater (1.12.0.7246): ...
+        [03] Console Debugger (0.1.0): Allow debugging plugins through the server console.
+
+  - type: textarea
+    id: debug-console
+    attributes:
+      label: Debug Console output
+      description: |
+        Add `"trace": true` to the launch configuration and reproduce once — it prints the
+        request/response flow the adapter saw.
+      render: text
+
+  - type: textarea
+    id: server-log
+    attributes:
+      label: Server log
+      description: |
+        Relevant lines from the server console and from
+        `addons/sourcemod/logs/errors_*.log`. If the server crashed, include the tail of the
+        console output and, on Linux, a backtrace if you have one
+        (`coredumpctl info` / `gdb -p`).
+      render: text

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,45 @@
+<!--
+Keep the description short and factual: what changes, and why it is the right
+change. The checklists below are the parts of this repo that are easy to break
+without noticing.
+-->
+
+## What and why
+
+<!-- One or two paragraphs. If it fixes a bug, say what the bug did, not just its name. -->
+
+Fixes #
+
+## How it was verified
+
+<!--
+Paste the result lines, not just "tests pass". If a suite was not run, say which
+and why -- that is more useful than silence.
+-->
+
+- [ ] `cd vscode && bun test` — unit suites
+- [ ] `cd vscode && bun tsc -p ./ --noEmit` — the `.vsix` job compiles every file under `src/`, tests included
+- [ ] `sp-console-debugger/tests/run_tests.sh` — console regression (needs the mock env)
+- [ ] `vscode/tests/dap/run_dap_tests.sh` — DAP regression + extension lifecycle (needs the mock env)
+- [ ] Built against **both** SourceMod lines (`--sm-path` at a 1.12 tree and at a 1.13/master tree)
+
+```
+<!-- result lines here -->
+```
+
+## Checklist
+
+- [ ] **Vendored tree**: if anything under `sp-console-debugger/` changed, `patches/sp-console-debugger.patch` was regenerated and the round-trip verified (delete the folder, refetch, re-apply, `diff -r` clean). See [docs/updating-upstream.md](../docs/updating-upstream.md).
+- [ ] **Windows**: no POSIX-only call without a guard, and no bare `std::min`/`std::max` in a file that pulls in `winsock2.h` (the `min` macro rewrites them and MSVC fails to compile).
+- [ ] **Teardown**: any new thread, socket or VM callback is released in `Stop()` / `SDK_OnUnload`. The extension is unloaded on `sm exts unload/reload` and on every server restart; anything still running then takes the game server with it.
+- [ ] **Debug surface**: if this adds or widens a DAP request, it cannot read or write more than the debugged plugin's own memory, and it is gated on a paused session where that matters.
+- [ ] **Docs**: user-visible behaviour is reflected in `docs/usage.md`, protocol changes in `docs/protocol.md`, design decisions in `docs/architecture.md`, new failure modes in `docs/troubleshooting.md`.
+- [ ] **Output**: any new Debug Console message is plain text (no decorative glyphs) and ends with a newline.
+
+## Risk
+
+<!--
+What breaks if this is wrong, and who notices first? Call out anything that
+changes the default configuration, the wire protocol, or the release packaging --
+those reach every server owner on the next update.
+-->