Generate RescueGroups.org API client with openapi-generator-cli

[Smoss]

Summary

This is the foundation for fixing #115 (multi-species support) and addressing the production failure of #124, which broke because the hand-rolled rescue_groups.py emitted a request shape the live API rejected, returning zero results.

Instead of continuing to hand-roll HTTP calls, this commit introduces a generated Python client for the RescueGroups.org v5 API, built from the community-maintained OpenAPI spec at https://github.com/api-evangelist/rescuegroups-org.

What's in this PR

• scripts/generate_rescuegroups_client.sh: regenerates the client from the OpenAPI spec, pinned to a specific commit SHA via gh api for reproducibility. Spec is fetched to /tmp and never written into the repo. Generator image: openapi-generator-cli:v7.23.0.
• vendor/rescuegroups_client/: the generated Python client. Only the package (rescuegroups_client/) and the generated docs/ are vendored; the script deletes CI configs, tests, build outputs, and generator metadata.
• .gitignore: ignore rules for the generated build artefacts and the unrelated generator cruft, in case a future generator version puts files in a new place.

Why this matters for #124

The merged rescue_groups.py from #124 built a search request with fieldName: "species.plural", criteria: "dogs"/"cats" and a filterProcessing: "1 OR 2" filter array. The live API returned zero results, and pick_pet raised ValueError("No elligible pet found") four minutes after the merge.

The canonical example in the upstream spec uses a different shape:

{
  "data": {
    "filters": [
      {"fieldName": "species.singular", "operation": "equal", "criteria": "Dog"}
    ],
    "geodistance": {"postalcode": "90210", "miles": 25}
  }
}

The new generated client uses this canonical shape. The likely cause of #124's failure was a field name mismatch (species.plural vs. species.singular) or the filterProcessing OR syntax not being accepted by the live API on the species-less /available/haspic endpoint.

Why it failed in CI

The unit tests for #124 mocked the HTTP session and only checked the request shape, not the live response. The dev.yml workflow runs with --debugsources --debugposters, which short-circuits to a SourceManual fixture — the live API was never exercised. This PR doesn't fix that, but the follow-up work below will.

Follow-up (not in this PR)

Before this can replace the existing rescue_groups.py, we need:

1. A wrapper in adoption_sources/ that adapts the generated client to the existing PetSource interface so main.py keeps working unchanged.
2. A live-API integration test gated on CUTEPETSBOSTON_RESCUEGROUPS_API_KEY, asserting the actual response — not just the request shape. This is the test that was missing for Add cats to adoptable pet pool (closes #115) #124.
3. Re-introduce multi-species search using the typed SearchRequest with the canonical body shape.

Test plan

• python -m pip install -e vendor/rescuegroups_client succeeds in a fresh venv.
• from rescuegroups_client.api.animals_api import AnimalsApi succeeds.
• Building a SearchRequest with SearchFilter(field_name='species.singular', ...) and serializing to dict produces the canonical body shape.
• git status shows only docs/ and rescuegroups_client/ under vendor/rescuegroups_client/ — no CI configs, no tests, no build artefacts.
• find . -name openapi.yml returns nothing (spec was never written into the repo).
• CI: Tests workflow passes (only the modified .gitignore should trigger).