feat(cli): add elastic status command to verify connectivity and auth

[MattDevy]

Summary

Adds elastic status, a top-level command that pings each configured service in the active context (elasticsearch, kibana, cloud) concurrently and reports per-service connectivity and auth. Closes #317.

$ elastic status
Context: local

  Elasticsearch  http://localhost:9200          ✓  green (3 nodes)
  Kibana         http://localhost:5601          ✓  available (8.18.0)
  Cloud          https://api.elastic-cloud.com  ✗  auth failed (401)

Under --json it emits { context, services: { elasticsearch?, kibana?, cloud? } } matching the shape in the issue. Exit code is 1 if any configured service fails, 0 if all succeed. Services missing from the context are omitted (not shown as errors). --use-context <name> plumbs through so a non-default context can be checked without switching.

Why this shape

• The handler does its own loadConfig and the preAction hook is bypassed for status (see src/cli.ts) so a partially broken config is reported as a structured config_error envelope rather than crashing before any probe runs. The issue explicitly calls this out as the reason a user reaches for status in the first place.
• Probes run concurrently via Promise.allSettled and each returns a structured { ok, ... } result; one failure cannot block another.
• The probes use raw fetch rather than the existing EsClient / KibanaClient / CloudClient classes because those throw on non-2xx, and status needs to classify HTTP failures (401/403 → auth failed, other non-2xx → request failed, fetch throws → network error) into per-row UX rather than propagating exceptions.

Other changes

• LoadConfigOk now exposes the resolved contextName so handlers can report which context they probed (used by the status handler when forming the output header).
• Auth-header construction (api_key → ApiKey ..., username+password → Basic ...) extracted to a new src/lib/auth.ts helper. Replaces duplicated logic in EsClient, KibanaClient, and the new status probes. Cloud client unchanged (api-key only).

Test plan

• npm run build clean
• npm test — 1257 unit tests pass (was 1258 before; one contrived edge-case test removed alongside the duplicate auth-header code it covered)
• npm run test:lint clean
• ./scripts/check-spdx clean on all new files
• Coverage on new module: src/lib/auth.ts 100/100/100; src/status/checks.ts 100/97.87/100; src/status/format.ts 100/95.45/100; src/status/register.ts 98.44/86.21/91.67 — all above the repo's 90% bar
• Manual smoke against an unreachable context: elastic status reports network error: fetch failed per row and exits 1
• Manual smoke with --json and --use-context nonexistent: {"error":{"code":"config_error","message":"Context \"nonexistent\" not found. ..."}} and exits 1
• Manual smoke with --dry-run: factory's generic dry-run path fires, exits 0, no HTTP calls

Out of scope

Latency reporting, TLS / cert diagnostics, and "did you mean…?" suggestions are all reasonable follow-ups but not in the issue's acceptance criteria.

[github-actions]

✅MegaLinter analysis: Success

Descriptor	Linter	Files	Fixed	Errors	Warnings	Elapsed time
✅ COPYPASTE	jscpd	yes		no	no	8.21s
✅ REPOSITORY	gitleaks	yes		no	no	55.76s
✅ REPOSITORY	git_diff	yes		no	no	0.64s
✅ REPOSITORY	secretlint	yes		no	no	32.92s
✅ REPOSITORY	trivy	yes		no	no	16.36s
✅ TYPESCRIPT	eslint	12		0	0	5.67s

Notices

📣 MegaLinter 9.5.0 is out! Discover the new features and security recommendations in the release announcement. (Skip this info by defining SECURITY_SUGGESTIONS: false)

See detailed reports in MegaLinter artifacts
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff

MegaLinter is graciously provided by OX Security
Show us your support by starring ⭐ the repository

[JoshMock]

👏