api: round out Agent, Operator, Catalog, Health, Coordinate, Event endpoints

[mbrulatout]

Summary

Phase 3 of the ongoing API-parity work (follow-up to #120/#121/#122) — closes out the remaining gaps tracked in ENDPOINT_STATUS.md for six existing endpoint groups, each as its own commit:

• Agent — leave(), reload(), metrics() (JSON + Prometheus), monitor() (single-shot, not true streaming — documented limitation), and a nested Agent.Token class for all five PUT /v1/agent/token/:type variants.
• Operator — raft peer removal/leader-transfer, autopilot config/health, keyring list/install/use/remove, usage. CE-only, per the earlier "no Enterprise" decision.
• Catalog — filter/peer/merge-central-config params, new gateway_services(), SkipNodeUpdate/TaggedAddresses on register().
• Health — filter/peer/merge-central-config params, new ingress().
• Coordinate — node() read, update() write.
• Event — dc on fire(), node/service/tag on list().
• Transport layer — HTTPClient.delete() gained a data param (needed by DELETE /v1/operator/keyring, which requires a JSON body — every other write method already had this, delete() was the one gap).

Bugs this surfaced (same pattern found twice)

PUT /v1/operator/autopilot/configuration with cas behaves exactly like Config.set()'s cas support from #121: always returns HTTP 200, with actual success/failure encoded as a JSON boolean body. Using status-only CB.boolean() there would have silently reported cas failures as successes — caught by a real integration test, fixed to use CB.json() matching the established Config precedent.

Other real findings from live-probing (not just docs)

• GET /v1/coordinate/node/:node 404s in a fresh dev-mode Consul until a coordinate is actually written for that node — LAN coordinates aren't pre-populated by gossip the way coordinate/datacenters (WAN) is.
• Event.list()'s node/service/tag params are accepted without error but have no observable filtering effect at list-time in a single-node topology — they appear to only gate gossip propagation at fire-time. Tests assert the real behavior, not the docs' implication.
• /catalog/services' bexpr tag selector is ServiceTags, not Tags.
• /catalog/node/:node's filter evaluates against each entry of the Services map, not the top-level document.
• Health.ingress() deliberately excludes peer/merge-central-config even though Consul doesn't error if you pass them — the canonical docs explicitly say ingress doesn't support them, so the client matches the documented contract over the lenient runtime behavior.

Test plan

• mypy consul/ --no-sqlite-cache — clean (32 source files)
• ruff check . / ruff format --diff . — clean
• New/extended integration tests across all six areas, run against real dockerized Consul (1.20.6/1.21.5/1.22.0) — 385 passing
• Full existing test suite re-run — no regressions (only the 6 pre-existing failures in the untracked, unrelated tests/test_features.py)
• Agent.monitor()'s test is intentionally scoped to the fast-fail path only (invalid loglevel → 400) — the success path is a genuinely unbounded blocking call with no per-request timeout anywhere in this library's transport layer, and there is no safe way to bound it from a test without either leaking a thread (Python's concurrent.futures atexit handler joins worker threads unconditionally, which would hang interpreter shutdown) or adding timeout support to std.py/aio.py, which is out of scope here.