Stop sending dfiq_type in DFIQ create and patch payloads

[tomchop]

Fixes #26.

yeti#1340 dropped dfiq_type from NewDFIQRequest, PatchDFIQRequest and DFIQValidateRequest, because the API now reads the type from the YAML or the object payload. All three models set model_config = ConfigDict(extra="forbid"), so anything this client sends in that field comes back as 422 Unprocessable Entity — Extra inputs are not permitted.

What changed

Three payloads stop carrying the field:

• new_dfiq_from_yaml → POST /api/v2/dfiq/from_yaml
• patch_dfiq_from_yaml → PATCH /api/v2/dfiq/{yeti_id}
• patch_dfiq → PATCH /api/v2/dfiq/{id}

Why the parameters stay

The issue offered a choice between deprecating dfiq_type and removing it. This keeps it, for one reason: it is the first positional parameter of both from_yaml methods. Removing it would rebind existing positional callers' arguments — new_dfiq_from_yaml("scenario", yaml) would pass "scenario" as the YAML — and no repo in the organisation calls these methods, so every consumer is external and invisible from here. The parameter is accepted, ignored, documented as ignored, and raises a DeprecationWarning. A clean removal belongs in the next major version, which the warning text says.

patch_dfiq needed no signature change; it was deriving the value from dfiq_object["type"] itself.

The other dfiq_type parameters in the client — find_dfiq, search_dfiq, download_dfiq_archive — are query filters, not request-body fields, and are untouched.

e2e coverage

Nothing in tests/e2e.py exercised any of the three methods, which is why this reached a release with a green e2e run. test_dfiq_from_yaml_and_patch now walks one scenario through all three against the live API. That matters because the unit tests only assert the payload the client builds — extra="forbid" is enforced by the server and nowhere else.

Verification

Unit and type checks, run the way CI does via poetry install --no-root:

• poetry run python -m unittest tests/api.py — 37 passed
• poetry run pyrefly check — 0 errors
• poetry run python -m unittest tests.e2e.YetiEndToEndTest.test_dfiq_from_yaml_and_patch against a live dev stack — passed

Also driven by hand against that stack, with the patched client, to confirm the fix rather than infer it:

auth: OK
new_dfiq_from_yaml: OK -> 17154206 client-check-47cef54a
  DeprecationWarning raised: True
patch_dfiq_from_yaml: OK -> Patched by the yeti-pyth
  DeprecationWarning raised: True
patch_dfiq: OK -> Patched as an object by the check
old payload with dfiq_type: HTTP 422
  detail: Extra inputs are not permitted

The last two lines are the same request with dfiq_type restored, i.e. what the current release sends — so the 422 in #26 is reproduced, and the new e2e test would catch the field coming back. Both test objects were deleted afterwards.

Release

Version is bumped to 2.3.1 in this PR, so no second commit on main is needed. Once this merges, the release still needs the bare tag (2.3.1) and a published GitHub release — publishing is what triggers the PyPI push.