feat(cli): add --debug flag and ELASTIC_DEBUG env var for HTTP request logging

## Summary

There is currently no way to see what HTTP request the CLI is actually sending when a command fails unexpectedly. A `--debug` flag (or `ELASTIC_DEBUG=1` env var) that logs outgoing requests and responses is the first thing a developer reaches for when troubleshooting.

## Proposed UX

```
$ elastic es cluster health --debug
> GET http://localhost:9200/_cluster/health
> x-elastic-client-meta: ...
> authorization: (redacted)

< 200 OK
< content-type: application/json

{ "cluster_name": "my-cluster", "status": "green", ... }
```

Alternatively as an env var:

```
ELASTIC_DEBUG=1 elastic es cluster health
```

Both forms should work. The flag takes precedence.

## Implementation notes

- Output should go to **stderr** so it does not interfere with `--json` or `--output-template` piping.
- **Credentials must be redacted** -- `Authorization` and `X-Api-Key` headers should be replaced with `(redacted)` in debug output. Never print raw secrets.
- Request body should be printed when present (e.g. `--input-file` or `--body` payloads).
- Response body should be printed as-is (it is already non-sensitive by definition of what the CLI returns).
- The debug flag should be a global root-level option (alongside `--json`, `--config-file`) so it applies to all subcommands without needing to be re-declared everywhere.
- All three HTTP clients (`EsClient`, `KibanaClient`, `CloudClient` in `src/lib/`) should honour it -- consider a shared `debugLogger` utility that each client calls after each request/response cycle.

## Acceptance criteria

- `elastic es cluster health --debug` prints request method, URL, sanitised headers, and response status to stderr
- `ELASTIC_DEBUG=1 elastic es cluster health` produces the same output
- Raw credential values never appear in debug output
- `--json` output is unaffected (debug goes to stderr, result goes to stdout)
- Works for ES, Kibana, and Cloud API calls