v2.0.0: migrate all resources to the real SuperOps GraphQL schema

[asachs01]

Background

Issue #4 revealed that this SDK was built against an assumed GraphQL schema that does not match SuperOps' real API. The server rejects nearly every query — wrong query arguments, wrong field names, wrong pagination model. CI never caught it because the test mocks (tests/mocks/handlers.ts) were hand-built to match the SDK's own incorrect assumptions.

This is a breaking, SDK-wide correction → v2.0.0.

Key schema differences (see SCHEMA.md)

• Queries take an input: argument object, not loose args (getAsset(input: AssetIdentifierInput!), not getAsset(id: ID!)).
• Pagination is page-based (ListInfoInput / <Entity>List { items, listInfo }), not GraphQL cursor connections.
• Object type field names differ throughout (assetId not id, hostName not operatingSystem, etc.).

Progress

• Shared page-based pagination layer (Page<T>, PageParams, page iterator)
• assets — migrated (v2.0.0: migrate all resources to the real SuperOps GraphQL schema #7)
• tickets
• clients
• sites
• alerts
• contracts
• technicians
• knowledge-base
• runbooks / patches / remote-sessions / reports — verify these map to real SuperOps entities at all; several may not exist in the API and should be dropped
• Rewrite tests/mocks/handlers.ts against real response shapes for every resource
• Remove the legacy cursor-based Connection/ListParams types once no resource uses them

Recommendation

The remaining resources should be migrated against an authoritative schema — a GraphQL introspection query against the live endpoint, or SuperOps' exported SDL. The public docs are sufficient to know field names but not to guarantee input-type fidelity (ListInfoInput shape, ListInfo field names remain unverified — see SCHEMA.md).

Test-gap fix

Each migrated resource needs mocks that reflect the real SuperOps response shape, and ideally a schema-contract check, so the SDK is never again validated only against its own assumptions.