error.rs: four Error variants (Shutdown, Config, EncodingError, PartialServerInit) are never constructed

[bug-ops]

Finding

mcpls_core::Error is #[non_exhaustive] and documents itself as following the Microsoft Rust Guidelines for error handling (structured variants over stringly-typed catch-alls). Grepping every variant's construction sites against the whole crate (excluding error.rs itself, where only unit tests construct them directly) shows four variants that are never constructed anywhere in production or test code:

• Error::Shutdown — 0 construction sites
• Error::Config(String) — 0 construction sites (its sibling InvalidConfig/ConfigNotFound are used 35+ times instead)
• Error::EncodingError(String) — 0 construction sites; bridge/encoding.rs::EncodingConverter (already flagged as dead code in negotiated LSP position encoding is never consumed by position conversion #290) returns bare Result<T, String> instead of crate::Error, so this variant has no producer even in principle
• Error::PartialServerInit — 0 construction sites (its sibling AllServersFailedToInit is used instead)

By contrast, Json/TomlDe/TomlSer also show 0 explicit Error::Variant(...) construction sites but are live — they're reached implicitly via #[from] + ? (e.g. config/mod.rs:519,537), so they are correctly excluded from this finding.

Downstream consumers of this #[non_exhaustive] enum must still write match arms (or a wildcard) accounting for these four variants, even though they can never actually fire. This is unnecessary public API surface and, in Config/PartialServerInit's case, duplicates the intent of a sibling variant that is used, which is confusing when reading the enum for the first time.

Location

crates/mcpls-core/src/error.rs:103 (Config), :152-153 (Shutdown), :174-176 (EncodingError), :232-241 (PartialServerInit)

Why

Dead variants in a public error enum are a maintenance trap: a contributor fixing a config-validation bug may reach for Error::Config (seemingly the general-purpose config error) not realizing InvalidConfig/ConfigNotFound are the ones actually wired up, and EncodingError misleadingly suggests position-encoding failures (a documented Critical Path per .claude/rules/continuous-improvement.md) go through the structured Error type when they currently don't. Either wire these variants up at their intended call sites, or remove them and let #[non_exhaustive] growth room absorb them later if genuinely needed.