Swift support, and the two silent LSP bugs it exposed

[yogthos]

Closes #778.

sourcekit-lsp ships with the toolchain, so the server half is a table entry. Adding it and then running it against a real SwiftPM package is what turned this into three fixes.

Swift

• swift LSP descriptor claiming .swift, rooted at Package.swift / compile_commands.json, launched as sourcekit-lsp (macOS has a /usr/bin shim onto the active Xcode; Linux toolchains put the real binary on PATH). .swift only — clangd claims the C-family extensions and is listed first, so a mixed target still sends .m to clangd.
• swift build / test / run, swiftlint, swift-format auto-allowed, same trust model as the cargo and go entries. Subcommands are named rather than allowing swift **, because swift foo.swift and swift repl run arbitrary code — the reason bare python is excluded — and swift package resolve fetches.
• claim_gate::segment_kind learned swift. Without it swift test matched the verifier's generic test token while the claim gate returned None, so a model told to verify, which verified, would be told it had not. That is dirge-hwk9.3 again, in a language neither recogniser knew about.

The two bugs it exposed, neither Swift-specific

A language server needs entries in three tables that don't reference each other: who claims the extension (builtin_servers), how to launch it (default_commands), and the languageId sent in didOpen (LANGUAGES). Miss the third and nothing errors anywhere — the server spawns, accepts the document as plaintext, and answers every query with nothing. Swift had that gap; so did clangd's .m/.mm and ruby-lsp's .rake/.gemspec, both already shipped. every_served_extension_has_a_language_id derives the check from the server registry, so claiming an extension now requires saying what language it is.

classify() identified a server→client request by its id's TYPE. Only numeric ids were accepted, so a request with a string id fell through to the notification arm and was dropped in silence. sourcekit-lsp sends client/registerCapability with a UUID and blocks until it is answered — so the server started, the file opened, and documentSymbol never came back. A request is identified by carrying both an id and a method; the ack now echoes the id verbatim. Found by teeing the LSP transport, not by reading the code.

Verification

Against a real SwiftPM package with the Xcode toolchain:

• documentSymbol returns the type tree (was (no results))
• definition on a call in the test target resolves into Sources/Greeter/Greeter.swift
• swift test runs with no prompt
• documentSymbol on this repo's own src/lsp/rpc.rs still returns rust-analyzer's symbols — the RPC change is not a regression

Full suite 5609 pass, four clippy configs and fmt clean.

Follow-ups filed

• dirge-3cfq — no tree-sitter-swift adapter, so the pre-write syntax gate doesn't cover .swift and the tree-sitter-backed find_definition / list_symbols return nothing for Swift (the lsp tool answers the same query correctly). There is precedent for LSP-without-adapter (cmake), so this is scope, not a defect in what shipped.
• A human-wait test flake seen twice in full-suite runs, unrelated to this change: anyone_waiting() is a process global, three production sites raise it, and only some tests take TEST_GATE. Diagnosed and filed rather than folded in.