feat(issuing): add scheduled_revocation_date, last_activated_on and update-card status

[armando-rodriguez-cko]

Summary
Adds card scheduledRevocationDate/status/lastActivatedOn per the 2026-09-17 swagger delta (INT-1700), and drops encryptedCvv from update-card-response (added by INT-1695, removed by this same delta). lastModifiedDate stays required; update-card-response is now typed as the full get-card-response field set per the current swagger allOf definition.

Changes

• CardRequest.java, VirtualCardRequest.java, PhysicalCardRequest.java — add-card-request gains scheduledRevocationDate
• UpdateCardRequest.java — update-card-request gains status (CardStatus) and scheduledRevocationDate
• CardDetailsResponse.java, CardResponse.java — get-card-response/add-card-response gain scheduledRevocationDate/lastActivatedOn
• UpdateCardResponse.java — expanded to the full get-card-response field set, drops encryptedCvv
• responses/activate/ActivateCardResponse.java (new) — typed response for activate-card, replacing VoidResponse
• IssuingClient.java, IssuingClientImpl.java — activateCard/activateCardSync now return ActivateCardResponse
• Test files updated/added for full coverage of the above

API Reference

• POST /issuing/cards
• PATCH /issuing/cards/{cardId}
• POST /issuing/cards/{cardId}/activate
• GET /issuing/cards/{cardId}

Breaking changes

• update-card-response no longer includes encryptedCvv (API-forced, minor per SDK, same precedent as INT-1695's activation_date rename).
• activateCard/activateCardSync return type changed from VoidResponse to ActivateCardResponse (source-breaking for callers with an explicit type annotation; API-forced, since the 200 body now carries a required field).

README
No README changes needed.

🤖 Generated with Claude Code

[agent-wall-e]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:257>250

Operational gates

• ✅ jira_ticket (INT-1700)
• ✅ independent_review

Files analysed: 14

---

_{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 — 257>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: Looks good to me

This PR still needs a human approval — wall-e cannot auto-approve it. For what it's worth, I read the diff and found nothing I'd block on.

Adds scheduledRevocationDate, lastActivatedOn, and CardStatus to issuing card request/response types, changes activateCard return type from VoidResponse to ActivateCardResponse, and expands UpdateCardResponse to the full get-card-response field set while dropping encryptedCvv — all consistent with the stated swagger delta. The diff is internally consistent and well-tested.

What I checked

• IssuingClient and IssuingClientImpl correctly swap VoidResponse for ActivateCardResponse in both async and sync paths, and the mock tests are updated to match.
• UpdateCardResponse is expanded to the full get-card-response field set including all fields present in CardDetailsResponse (id, cardholderId, status, type, scheme, scheduledRevocationDate, lastActivatedOn, isSingleUse, etc.) and drops encryptedCvv as claimed.
• CardDetailsResponse and CardResponse both gain scheduledRevocationDate/lastActivatedOn; the old revocationDate is marked @deprecated with a clear override note, which is a safe backward-compatible approach.
• VirtualCardRequest and PhysicalCardRequest constructors both thread scheduledRevocationDate through to setScheduledRevocationDate(), matching the base class addition in CardRequest.
• UpdateCardRequest gains both status (CardStatus) and scheduledRevocationDate, and the Javadoc correctly documents the mutual-exclusion constraint with scheduledActivationDate.
• The new CardScheduledRevocationAndActivationSerializationTest covers round-trip serialization for all new fields including the edge case of null lastActivatedOn and the ignored encrypted_cvv field.
• The old shouldDeserializeWithEncryptedCvv / shouldSerializeEncryptedCvvUsingTheSwaggerKey tests are removed from CardUpdateResponseSerializationTest; equivalent coverage for the current field set is provided in the new serialization test class.
• UpdateCardResponse does not extend CardDetailsResponse (it duplicates the fields) — this is a deliberate flat layout rather than inheritance, which avoids coupling but means any future CardDetailsResponse additions won't propagate automatically; not a bug, but worth the reviewer being aware of.
• ActivateCardResponse is a minimal final class with only lastActivatedOn, which matches the described swagger response body.

⚠️ 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:256>250

Operational gates

• ✅ jira_ticket (INT-1700)
• ✅ independent_review

Files analysed: 14

---

_{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 — 256>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