Add per-cluster TLS verification options for self-signed clusters

[maxcold]

Summary

• Add per-cluster sslVerify (default true) and caCertPath options to CLUSTERS_JSON / CLUSTERS_FILE, with startup validation that rejects the insecure combination of both set.
• Wire a shared https.Agent into the Elasticsearch and Kibana axios clients so self-signed or private-CA clusters can connect without opaque fetch failed errors.
• Expose a Verify SSL/TLS Certificates checkbox in the MCPB install dialog and document the options across setup guides.

Closes #12

How to test

Install .mcpb in Claude Desktop, uncheck SSL verification, point at a self-signed local cluster, confirm tool calls succeed

[davethegut]

Approve — verified end-to-end with a self-signed local cluster

Pulled this branch and walked through the full TLS surface against a fresh self-signed ES (yarn es snapshot --ssl --license=trial, default kbn-dev-utils CA). Build is green, 392/392 unit tests pass, and every runtime path behaves the way the docs claim.

What I tested (stdio harness against self-signed https://localhost:9200)

Config	Expected	Actual
sslVerify omitted (default true)	Clean cert error, not opaque "fetch failed"	"self-signed certificate in certificate chain" ✓
sslVerify: false	Tool succeeds + stderr warning	Succeeds; logs cluster "primary": TLS certificate verification is DISABLED… ✓
caCertPath: <real CA>	Tool succeeds + stderr info	Succeeds; logs cluster "primary": using custom CA bundle for TLS verification ✓
sslVerify: false + caCertPath	Startup rejection	exits 1: sslVerify is false but caCertPath is set — pick one ✓
caCertPath: <missing file>	Startup rejection	exits 1: cannot read caCertPath for cluster primary: ENOENT… ✓
Legacy config (no sslVerify)	Back-compat, defaults to true	Identical behavior to default-true path ✓
http-only cluster	No agent created, no TLS log noise	Confirmed (createHttpsAgent returns undefined) ✓

Claude Desktop install dialog (.mcpb)

Built .mcpb, fresh-installed in Claude Desktop:

• ✅ "Verify SSL/TLS Certificates" renders as a checkbox, checked by default
• ✅ Unchecking it stores ssl_verification: false (boolean, not string) in the extension settings
• ✅ ${user_config.ssl_verification} substitutes into CLUSTERS_JSON.sslVerify correctly as a raw JSON boolean
• ✅ End-to-end round-trip: unchecked box → server applies rejectUnauthorized: false → real tool call against self-signed ES succeeds

Bonus benefit worth highlighting

The new error surface is a real win even for users who keep sslVerify: true. Pre-PR, a self-signed cluster surfaced as opaque "fetch failed"; with this PR it returns "self-signed certificate in certificate chain", which is immediately diagnosable from the tool output. That alone would be a useful change.

One non-blocking UX nit

In the .mcpb install dialog, the warning copy on the SSL checkbox visually runs into the preceding sentence — would benefit from a paragraph break:

- "description": "Verifies the Elasticsearch / Kibana TLS certificate against trusted CAs. ⚠ Uncheck ONLY if you are connecting to a trusted self-signed development cluster — disabling verification removes protection against man-in-the-middle attacks."
+ "description": "Verifies the Elasticsearch / Kibana TLS certificate against trusted CAs.\n\n⚠ Uncheck ONLY if you are connecting to a trusted self-signed development cluster — disabling verification removes protection against man-in-the-middle attacks."

(Worth confirming Claude Desktop honors \n in description fields — if it strips them, an alternative is to lead with the warning, e.g. "⚠ Uncheck ONLY for trusted self-signed dev clusters. Verifies the Elasticsearch / Kibana TLS certificate against trusted CAs; disabling removes protection against man-in-the-middle attacks.")

LGTM. 🚢

[davethegut]

LGTM