fix(graphql): select the reconciling-item fields on the fiscal calendar query

[jfrench9]

Summary

Closes the gap the post-merge review of #194 found: the 1.12.0 schema refresh added reconcilingItemCount / reconcilingItemSample to FiscalCalendar, but the GetLedgerFiscalCalendar operation document was never updated to select them, so the typed GraphQL model exposed neither field while the REST FiscalCalendarResponse carried both.

Changes

• robosystems_client/graphql/operations/ledger/GetLedgerFiscalCalendar.graphql — selects the two fields.
• robosystems_client/graphql/generated/get_ledger_fiscal_calendar.py, generated/operations.py — output of just generate-graphql, unedited: reconciling_item_count: int and reconciling_item_sample: list[str] on GetLedgerFiscalCalendarFiscalCalendar (required, matching Int! / [String!]! in the schema), and the query string.
• tests/test_ledger_client.py — both fiscal-calendar fixtures carry the fields and both tests assert them.

Procedural note for the next regen: just refresh-schema updates the snapshot, but the operation .graphql documents are hand-maintained — a new field on a type is not selected until its query is edited.

Compatibility

Additive on the generated tier (two new attributes on a generated Pydantic model; LedgerClient.get_fiscal_calendar returns the same type with more data). Rides the next client minor per the two-tier contract; no facade signature changes. Callers constructing GetLedgerFiscalCalendarFiscalCalendar by hand from a payload that predates 1.11 of the API would now fail validation — the server has returned both fields since API v1.11.0, and the model is a response type, not an input.

Testing

• just test-all — 526 passed, 17 skipped; ruff format, ruff check, basedpyright clean
• just generate-graphql is clean after the edit (the drift gate's condition)

[jfrench9]

@claude please review this PR

[claude]

Claude finished @jfrench9's task in 1m 3s —— View job

---

Review complete ✅

• Gather context (diff, schema, related files)
• Understand the request
• Review changed files
• Post review feedback

Verdict: Looks good — no changes requested.

This is a small, well-scoped fix and every changed file is internally consistent:

• robosystems_client/graphql/schema.graphql:1222-1227 confirms reconcilingItemCount: Int! and reconcilingItemSample: [String!]! on FiscalCalendar — matching the non-Optional int / list[str] fields added to GetLedgerFiscalCalendarFiscalCalendar in get_ledger_fiscal_calendar.py:32-33.
• The .graphql operation document (GetLedgerFiscalCalendar.graphql:10), the embedded query string in generated/operations.py, and the generated Pydantic model all select/expose the same two fields — no drift between them.
• LedgerClient.get_fiscal_calendar (clients/ledger_client.py:1957-1960) just does GetLedgerFiscalCalendar.model_validate(data).fiscal_calendar with no manual field mapping, so the PR's claim of "no facade changes needed" checks out — the new fields flow through automatically.
• tests/test_ledger_client.py fixtures/assertions cover both the zero-item and one-item cases, which is adequate for a purely additive field addition.
• The one-line-per-related-fields style on the new .graphql line (reconcilingItemCount reconcilingItemSample) matches the file's existing formatting convention (see the strandedObligation*/lastCloseAt initializedAt lastSyncAt lines nearby), so no nit there either.

One caveat: I couldn't execute just test-all / pytest in this sandboxed review environment (shell execution isn't approved here), so I wasn't able to independently reproduce the "526 passed" result. Given the change is purely additive and mechanically traceable end-to-end (schema → .graphql → generated model → test fixtures), the risk of a regression is low.

Nice catch closing the gap from the #194 post-merge review, and thanks for the "operation .graphql documents are hand-maintained" note for future regens — that's a good callout for anyone touching just refresh-schema next.