Baixar agent-lsp 0.21.0 per a Windows

### Added
• **Pi coding agent support** ([#36](https://github.com/blackwell-systems/agent-lsp/pull/36))：`agent-lsp init` targets 9 (project) and 10 (global) configure [Pi](https://github.com/earendil-works/pi) through the `pi-mcp-adapter` package, writing the MCP config to `.mcp.json` or `~/.config/mcp/mcp.json` and skill awareness rules to `AGENTS.md` or `~/.pi/agent/AGENTS.md`; `uninstall` and `skills/install.sh` cover Pi's files too. Contributed by [@davalillo](https://github.com/davalillo).
• **`agent-lsp init --with-skills`** ([#36](https://github.com/blackwell-systems/agent-lsp/pull/36))：one-command setup that also installs the embedded skills (with their reference files) to the destination matching the chosen tool, no repo clone needed. Installs never write through a symlink planted in the destination, whether at a skill file or a skill directory, so a cloned project cannot redirect the write outside it; installed files are world-readable (0644). Contributed by [@davalillo](https://github.com/davalillo).

### Fixed
• **Dynamic capability registration no longer overwrites provider options** ([#37](https://github.com/blackwell-systems/agent-lsp/issues/37))：the `client/registerCapability` handler stored every dynamically registered method as a plain `true` boolean, destroying any options object the server had declared in `initialize` — e.g. mql-lsp-server declares `renameProvider: {"prepareProvider": true}` and then registers `textDocument/rename`, after which the stored capability became the bool `true` and `prepare_rename` never sent `textDocument/prepareRename` at all. Registrations now merge `registerOptions` over the existing value (an existing options map is kept when the registration carries no options; an existing bool `true` acts as an empty base for incoming options), and the debug log records whether each registration merged, kept, or set-true.
• **`prepare_rename` reports unsupported/null outcomes in words instead of empty output** ([#39](https://github.com/blackwell-systems/agent-lsp/issues/39))：when the server does not implement `textDocument/prepareRename` (or its declared support is masked, as in [#37]), the tool returned a single empty text content — rendered "(no tool output)" by clients and indistinguishable from a hang. It now returns "prepare_rename is not supported by this language server; rename_symbol may still work." for the capability gap, and "The server returned no rename range at this position; a rename here may not be valid." (plus a dry-run hint) when the server answered null. Defense in depth: `gcf.Encode(nil)` returns `null` instead of an empty string, so no tool can emit a silent empty content for a nil result.
• **`blast_radius` no longer treats nested parameters and locals as targets on non-Go languages** ([#41](https://github.com/blackwell-systems/agent-lsp/issues/41))：the exported-symbol walker applied Go export semantics to every language (for anything but Go, `langID != "go"` made every symbol "exported"), skipped only fields (kind 8), and recursed into children unconditionally. Servers that report a rich `textDocument/documentSymbol` tree nest parameters and local variables as children of functions (verified with mql-lsp-server v2.4.2: kind-12 functions with kind-13 children), so all of them became blast-radius "targets" — on a real MQL project, 48 targets mixing functions with parameters and locals. `scope=exported` now restricts nested symbols (depth > 0) to container/callable kinds (Module, Namespace, Package, Class, Method, Constructor, Enum, Interface, Constant, Struct, Event) and stops descending into excluded symbols, so parameters, locals, fields, properties, enum members, and literal-ish kinds are left out; function-local constants are excluded too (a nested constant stays a target only inside a container kind such as a class or namespace), top-level behavior and the Go uppercase rule are unchanged, and `scope=all` still reports the other excluded nested symbols (fields remain excluded there as well) for dead-code detection of internal helpers.
• **`find_references` empty-result hint no longer asserts dead code unconditionally** ([#38](https://github.com/blackwell-systems/agent-lsp/issues/38))：zero references has at least two causes — the symbol is genuinely unreferenced, or the language server could not resolve references for that position (index state, cross-file limitations, servers that only index opened documents). The old hint ("This symbol may be dead code") was a false positive pushing agents toward deleting used code on exactly those servers; it now reads "No references found. This may be dead code, or the language server could not resolve references for this position — use /lsp-dead-code to verify."
• **`find_references` / `go_to_definition` fuzzy fallback now validates the hover symbol and marks fallback results** ([#40](https://github.com/blackwell-systems/agent-lsp/issues/40))：when a direct position lookup returned nothing, the fuzzy fallback hovered at the cursor, extracted a symbol name from the hover, and re-queried workspace symbols for it. Some servers (observed with mql-lsp-server v2.4.2) answer a hover at an unresolvable call site with the *containing* symbol, so the fallback resolved the wrong symbol and returned the containing function's body as "the definition" of the called function — a confidently wrong answer with no provenance marker. The fallback now compares the hover symbol against the identifier at the queried position and skips when they differ, and any result it does produce carries the provenance hint "Result produced via fuzzy position fallback — verify the symbol identity before use." so agents can weigh it accordingly.
• **`get_diagnostics` no longer calls an unverified empty result "safe to proceed"; edit-tool post-verification marks a dead diagnostics channel `unverified`** ([#44](https://github.com/blackwell-systems/agent-lsp/issues/44))：an empty diagnostics map has two meanings — the server analyzed the document and found nothing, or the server never published any diagnostics at all (agent-lsp implements neither the LSP 3.17 pull model nor a push fallback). A server that declares `diagnosticProvider` but never emits `publishDiagnostics` (observed with mql-lsp-server v2.4.2) fell into the second case, yet the tool returned "No errors. Safe to proceed." and recommended proceeding on files with flagrant syntax errors. The client now records whether *any* `publishDiagnostics` notification was ever received per document (`HasPublishedDiagnostics`; a published empty array counts as delivered, and cached replays through `SubscribeToDiagnostics` are not treated as new publishes). `get_diagnostics` keeps "No errors. Safe to proceed." only when the channel delivered for that document; when nothing was ever published it now says "No diagnostics received — the server has not published any for this document; this does not confirm the file is clean.", and a mixed multi-document query keeps the safe hint for the live files while listing the unconfirmed ones. `rename_symbol`, `replace_symbol_body`, `insert_after_symbol`, `insert_before_symbol`, and `safe_delete_symbol` post-verification now annotates `errors_after`/`warnings_after` with "(unverified: the server published no diagnostics for this document — channel may be dead)" when the channel is dead, so the audit record does not assert a verification that never happened.
• **`restart_lsp_server` could fail or leave the new server unreachable**：after a restart, the previous server process's exit monitor and read loop kept writing the client's shared state. If the old process finished exiting after the new one had started, its monitor cleared the new server's stdin and rejected its pending `initialize` request ("LSP process has exited"), and its read loop could consume the new server's output alongside the new loop, so responses were lost and requests timed out. `Shutdown` also called `cmd.Wait` concurrently with the monitor and returned without waiting after force-killing a slow server. Each process's goroutines now act only on their own process: the monitor is the sole waiter and touches client state only while its process is current, `Shutdown` (and so `Restart`) waits for the monitor to finish, including after a kill, and each read loop stops once its connection is replaced. This was the intermittent CI failure in `multi-lang-core` (Kotlin) and `mcp-assert`. Also drops a stray `%!w(<nil>)` from the error after a clean exit.
• **`agent-lsp uninstall --help` performed a real uninstall**：`init` and `uninstall` ignored arguments they did not recognize, so `uninstall --help` removed agent-lsp's MCP entries, skills, rules sections, and caches, and `init --help` ran setup with defaults. Both now print usage for `-h`/`--help`/`help` without changing anything, and reject unknown arguments instead of running.
• **`uninstall` now removes every rules section `init` writes**：it cleaned only `~/.claude/CLAUDE.md` and the two Pi `AGENTS.md` files, leaving the managed section behind in a project `CLAUDE.md`, `GEMINI.md`, `.clinerules`, `~/.windsurfrules`, and `.cursor/rules/agent-lsp.mdc`. The list is now derived from `init`'s own paths. Also from [#36](https://github.com/blackwell-systems/agent-lsp/pull/36): `uninstall` looked for the wrong sentinel markers and never removed the rules block at all, left empty config and rules files behind, and removed any `lsp-*` skill directory (now only the skills agent-lsp ships); scripted `init` read EOF for every prompt after the first and silently fell back to choice 1.
• **`rename_symbol` post-edit verification is bounded and stays in the workspace**：it now checks the diagnostics channel of every file the rename edited, not only the requested one, with one shared wait (a large rename against a server that never publishes no longer blocks for minutes), and it skips any file outside the workspace root instead of reading it.

### Changed
• **C