feat(inventory): add Inventory endpoint family

[armando-rodriguez-cko]

Summary

Implements the new Inventory product added to the API on 2026-09-10: stock adjustments,
atomic multi-variant reservations (create/get/commit/release), stock levels (get/set), and
beta product knowledge (get/set/delete). All 10 endpoints require the OAuth scope
agentic:inventory, no secret/public key support, reusing this SDK's existing
AuthorizationType.OAUTH client pattern (agentic:inventory was already present in
OAuthScopes).

Also verified the same swagger diff's PaymentSessionCaptureFlag/PaymentSessionCaptureOn
and PaymentInterfacesPanPreference/PaymentInterfacesProvisionNetworkToken schema
extraction: confirmed no-op for this SDK.

Changes

• checkout_sdk/inventory/inventory.py — request/response classes (InventoryAdjustmentRequest,
  InventoryLevels, InventoryReservation, InventoryReservationItem,
  InventoryReservationRequest, InventorySetLevelsRequest, InventoryProductKnowledge,
  InventorySetProductRequest, InventoryHalLink, InventoryMoney) and enums
• checkout_sdk/inventory/inventory_client.py — new InventoryClient, all 10 methods.
  Error shape (request_id, error_type, error_codes, variant_id, available)
  documented in docstrings, surfaced via the SDK's existing CheckoutApiException rather
  than a dedicated per-domain error class
• checkout_sdk/checkout_api.py — wired the new client in
• tests/inventory/ — client and serialization tests, 677 passing overall

API Reference

• POST /inventory/adjustments
• POST /inventory/reservations
• GET /inventory/reservations/{id}
• POST /inventory/reservations/{id}/commit
• POST /inventory/reservations/{id}/release
• GET /inventory/{variant_id}
• PUT /inventory/{variant_id}
• GET /inventory/{variant_id}/product (Beta)
• PUT /inventory/{variant_id}/product (Beta)
• DELETE /inventory/{variant_id}/product (Beta)

Breaking changes

None. Purely additive.

README

No README changes needed.

[agent-wall-e]

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

• exceeds_bounded_scope:695>250

Operational gates

• ✅ jira_ticket (INT-1698)
• ✅ independent_review

Files analysed: 7

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
exceeds_bounded_scope — 695>250	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[agent-wall-e]

🟠 Advisory review: Concerns worth a look

This PR needs a human approval. Before you give it, these are the things I'd want resolved.

Adds a new InventoryClient with 10 endpoints wired into CheckoutApi; the structure follows existing SDK patterns correctly, but there are concrete issues around the InventoryLevelsQuery handling and the serialization test's assertion of _links with _ prefix.

Concerns

• In inventory_client.py, get_inventory_levels accepts an InventoryLevelsQuery but the diff is truncated before showing how it's passed to _api_client.get — if the query object is passed as a request body (3rd arg) rather than as query params, GET requests with a body would silently fail or be ignored by the server; this needs to be verified against the full diff.
• The serialization test test_deserializes_every_property_from_the_swagger_example manually constructs an InventoryReservation object and then serializes it back, asserting it equals the original payload including '_links': {...} — but the field is named _links (with leading underscore), which in Python serialization (e.g. via JsonSerializer) may be stripped of its leading underscore or skipped entirely depending on how the serializer handles name-mangled or private-looking attributes; this assertion may be a false positive if the serializer silently drops _links.
• The commit_inventory_reservation and release_inventory_reservation methods call _api_client.post with no request body argument — if the underlying ApiClient.post signature requires a body positional argument (not optional), this will raise a TypeError at runtime; needs verification against the base ApiClient.post signature.
• The data model classes (InventoryAdjustmentRequest, InventoryReservation, etc.) use bare class-level type annotations without __init__ or dataclass decoration, relying entirely on dynamic attribute assignment — this is consistent with the rest of the SDK pattern, but means missing required fields silently serialize to empty objects with no validation, which is a correctness risk for required fields like variant_id, delta, reason.
• The assert_api_call helper is reused from existing tests but the test for delete_inventory_product and get_inventory_product both assert path 'inventory/var_123/product' — correct, but since one is a DELETE and one is a GET, if assert_api_call only checks the path and not the HTTP method, the routing assertion provides weaker coverage than it appears.
• The diff is explicitly truncated in multiple places (inventory.py at line ~412, inventory_client.py mid-method, and the serialization test), so completeness of the InventoryLevelsQuery class definition, the set_inventory_levels/get_inventory_product/set_inventory_product/delete_inventory_product client method implementations, and the full serialization test suite cannot be verified.

⚠️ The diff was too large to read in full, so this review covers only part of the change.

---

_{This is not an approval. wall-e cannot auto-approve this PR — it is an opinion to help whoever does. Advisory review · us.anthropic.claude-sonnet-4-6 · wall-e 2026.06.19-02}

[agent-wall-e]

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

• exceeds_bounded_scope:607>250

Operational gates

• ✅ jira_ticket (INT-1698)
• ✅ independent_review

Files analysed: 7

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
exceeds_bounded_scope — 607>250	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud