fix: accept valid repeated checkout cancellation responses

[ShuoRen-TT]

Description

This fixes #54 by updating the repeated checkout cancellation conformance test to accept both protocol-compatible outcomes:

• a 4xx client error, as recommended for an already canceled checkout
• a 200 response containing the same checkout in the canceled state, for implementations that treat cancellation as an idempotent operation

The previous assertion rejected every 200 response while accidentally allowing redirects and server errors. The revised test validates the returned checkout when cancellation succeeds and limits error responses to the 4xx range.

Fixes #54.

Validation

• Ran all 11 tests in checkout_lifecycle_test.py against the latest Flower Shop sample server
• Verified that 200 + canceled is accepted
• Verified that a mismatched successful state and 503 are rejected
• Ran Ruff check, Ruff format check, Codespell, and git diff --check

Type of change

• Bug fix (non-breaking change which fixes an issue)

---

Is this a Breaking Change or Removal?

No.

Breaking Changes / Removal Justification

Not applicable.

---

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• The new logic is self-explanatory and does not require additional comments
• Documentation changes are not required; this aligns the test with existing protocol behavior
• My changes generate no new warnings
• I have updated the conformance test to prove the fix is effective
• New and existing tests pass locally with my changes
• No dependent downstream changes are required

---

Pull Request Title

This PR uses the required Conventional Commits format.

[nicholasjameshall]

nit: afaik there should be a standard library in Python for these errors

[ShuoRen-TT]

Thank you for the suggestion and for reviewing this! You are right that http.HTTPStatus.OK would be clearer than the literal 200. For the 4xx range, the repository supports Python 3.10, while HTTPStatus.is_client_error is only available from Python 3.12, so the compatible cleanup would be to use HTTPStatus.OK together with httpx.Response.is_client_error. I will keep that pattern in mind when the suite status assertions are consolidated. I really appreciate you pointing this out.