[BUG] clangd-lsp plugin (and likely other bundled LSP plugins) missing lspServers config after install

Environment

• Claude Code version: 2.1.224
• OS: Windows 10
• Marketplace: claude-plugins-official
• Plugin: clangd-lsp v1.0.0

Bug

The marketplace manifest (.claude-plugin/marketplace.json) correctly declares an lspServers block for clangd-lsp:

"lspServers": {
  "clangd": {
    "command": "clangd",
    "args": ["--background-index"],
    "extensionToLanguage": { ".c": "c", ".h": "c", ".cpp": "cpp", ... }
  }
}

However, after installing the plugin via the marketplace, the locally installed copy at ~/.claude/plugins/cache/claude-plugins-official/clangd-lsp/1.0.0/.claude-plugin/plugin.json contains only name, description, version, and author -- the entire lspServers block is missing. As a result, clangd is never invoked (no process ever starts, no .cache index directory is created, pluginUsage.usageCount stays at 0), even though clangd.exe is installed and on PATH.

Repro

1. Install clangd-lsp from claude-plugins-official.
2. Open/edit a .cpp/.h file in a Claude Code session.
3. Check for a running clangd process, a .cache/clangd index directory, or any clangd-related entries in ~/.claude/daemon.log -- none appear.
4. Compare the installed .claude-plugin/plugin.json against the plugin's entry in ~/.claude/plugins/marketplaces/claude-plugins-official/.claude-plugin/marketplace.json -- the lspServers key present in the marketplace manifest is absent from the installed copy.

Expected: the lspServers config from the marketplace manifest should be carried over to the installed plugin during install/sync, so clangd actually gets wired up.

Additional gap: even the marketplace manifest's extensionToLanguage map for clangd-lsp is incomplete -- it is missing .inl (a common C++ inline-definition-file extension used in header/.inl/.cpp triplets in some codebases). Suggest adding ".inl": "cpp" alongside the existing .h/.hpp/.hxx entries.

Workaround applied locally: manually copying the lspServers block from marketplace.json into the installed plugin.json, plus adding the missing .inl mapping, fixes it (pending confirmation after a session restart) -- but this is fragile since a future plugin update will likely overwrite it again.