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
SdkAuthorizationType.OAUTH client pattern.

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

Changes

• com/checkout/inventory/ — new InventoryClient/InventoryClientImpl, request classes
  (InventoryAdjustmentRequest, InventoryReservationRequest, InventorySetLevelsRequest,
  InventorySetProductRequest, InventoryLevelsQueryFilter), response classes
  (InventoryLevels, InventoryReservation, InventoryProductKnowledge), shared types
  (InventoryHalLink, InventoryMoney, InventoryReservationItem) and enums
• com/checkout/inventory/InventoryClient.java — Javadoc documents the 404/409/422 error
  shape surfaced through the SDK's existing generic CheckoutApiException, no dedicated
  per-domain error class (none exists elsewhere in this SDK)
• CheckoutApi.java / CheckoutApiImpl.java — wired the new client in
• src/test/java/com/checkout/inventory/ — serialization and client tests, 40 passing

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:1546>250

Operational gates

• ✅ jira_ticket (INT-1698)
• ✅ independent_review

Files analysed: 26

---

_{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 — 1546>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.

This PR adds a new Inventory client family with 10 endpoints, wiring, request/response types, and tests. The implementation is generally well-structured, but there are two concrete problems: a missing @SerializedName annotation on camelCase fields in request/response classes (which the SDK uses Gson for), and the getInventoryLevels overload with a null filter will throw rather than degrade gracefully.

Concerns

• InventoryReservationItem has fields variantId and quantity but no @SerializedName annotations — the serialization test asserts "variant_id" in the JSON output, which would only work if the SDK's Gson config has a camelCase-to-snake_case naming policy globally; if any other request/response class (e.g. InventoryAdjustmentRequest.variantId, InventorySetLevelsRequest.onHand, InventoryReservationRequest.ownerType/ownerReference/ttlSeconds) also lacks @SerializedName the wire format depends entirely on that global policy being set — this needs verification since model3dUrl in InventorySetProductRequest does have an explicit @SerializedName("model_3d_url"), suggesting the global policy may NOT cover all cases automatically.
• In InventoryClientImpl, getInventoryLevels(variantId, filter) calls CheckoutUtils.validateParams("variantId", variantId, "filter", filter) which will throw an IllegalArgumentException if filter is null — callers who want to pass a filter for only some fields (leaving others null) or who accidentally pass null will get a hard failure rather than falling through to the no-filter overload; the no-arg overload exists but is not delegated to.
• The diff is truncated — the full InventoryClientImpl (past the setInventoryProduct call), the full InventorySetProductRequest (past harmonizedSystemCode), the full InventoryProductKnowledge response (past sellerName), and the full test file for client tests are not visible, so bugs in deleteInventoryProduct path-building or any missing @SerializedName on later fields cannot be confirmed.
• InventoryMoney uses @NonNull on Long amount — Lombok @nonnull on a primitive wrapper means a NullPointerException at construction time if null is passed, which is the intended behavior, but deserialization via Gson bypasses the constructor entirely and will silently leave the field null without throwing, making the @nonnull guarantee misleading for deserialized responses.
• No integration/sandbox test is present (only unit/serialization tests), which is consistent with the rest of the SDK but means the OAuth scope requirement and actual wire format have not been exercised end-to-end in this PR.

⚠️ 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}

[sonarqubecloud]

Quality Gate passed

Issues
10 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud