Module capabilities 

Client capability advertisement (sent during initialize) and server capability storage (returned by initialize).

Advertise discipline

Per LSP spec, advertising a capability obliges the client to handle the corresponding server behaviour. We grow the advertised set in lockstep with feature implementations:

Phase	Capability bucket
4.1 (this commit)	general (encoding + stale-request), workspace (applyEdit, configuration, workspaceFolders), textDocument.synchronization, textDocument.publishDiagnostics
4.2	textDocument: hover, definition/declaration/typeDefinition/implementation, references, documentSymbol, workspace.symbol, completion
4.3	textDocument: codeAction, rename, formatting/rangeFormatting/onTypeFormatting, signatureHelp
4.4	textDocument: semanticTokens, inlayHint, foldingRange, documentHighlight, selectionRange, callHierarchy, etc.

Each phase ADDs to client_capabilities; the server side gating just reads from Capabilities and skips features the server didn’t advertise back.

Position encoding

We prefer utf-8 (LSP 3.17 introduced general.positionEncodings). Most modern servers honour the negotiation; older ones default to utf-16, which we handle via the column converter (queued for 4.1.c). Keeping both in the advertised list lets us survive servers that ignore positionEncodings entirely.

Structs

Capabilities

Snapshot of the negotiated capabilities. The actor publishes one of these through an arc_swap::ArcSwap cell on the ServerHandle (4.4.n); per-feature dispatch loads a fresh snapshot before issuing a request.

Enums

FileOpKind

4.4.m: discriminator for the six file-operation hooks. Used by Capabilities::file_operations_options so probes don’t repeat the server.workspace.as_ref().and_then(|w| w.file_operations.as_ref()) walk; the enum names the field instead.

Functions

client_capabilities

Build the full set of capabilities the client advertises in initialize. Pure – safe to call from any task / thread.