test(openapi): add executable coverage checks between client handlers and bundled spec

[joshrotenberg]

Summary

The repo vendors an OpenAPI fixture and has some validation tests, but the current checks are mostly structural. They verify that the fixture loads, has enough endpoints, and contains expected categories/schemas. They do not currently prove that the client covers the advertised routes or that uncovered API paths are explicitly tracked.

Why this matters

The README claims comprehensive REST API coverage, but CI does not have an executable check that connects handler methods to the bundled spec. That makes it easy for coverage claims and implementation reality to drift apart.

Current validation

• tests/openapi_validation.rs
• tests/fixtures/cloud_openapi.json

Gaps

• no machine-readable inventory of implemented routes/methods
• no allowlist for intentionally unsupported endpoints
• no CI guard that flags newly added spec paths as uncovered work
• no route-level coverage signal to complement issue docs: OpenAPI spec deltas - fields missing from official spec #40 (schema delta tracking)

Suggested direction

• define a route inventory for the Rust client (manually maintained table or generated metadata)
• compare that inventory against the bundled spec in CI
• keep an explicit allowlist for intentionally deferred endpoints
• use the resulting report to drive follow-up coverage issues instead of relying on README claims alone

Acceptance criteria

• CI fails when a spec path/method becomes uncovered without an explicit allowlist entry
• the repo contains a machine-readable inventory or mapping of supported routes
• intentionally unsupported or deferred endpoints are tracked explicitly
• README/docs coverage claims align with the executable check