feat: add new endpoint for reset password

[Karpakamani-r]

Summary of Changes

Adds a new versioned "Reset Password" API (20260428) that replaces the existing two-step, POST-based reset password flow with a single PUT-based endpoint, as per the MDX spec. This aligns the reset password flow with the pattern already used by other versioned MDX endpoints (a single PUT request/response using challenges, with no separate initiate/answer split).

The previous POST-based flow (POST /reset_password and PUT /reset_password/challenges/{challengeId}) is marked @Deprecated but left fully functional, no accessor is required to implement the new endpoint immediately, and existing accessors continue to work unchanged.

Jira: MC-14857

Fixes # (issue)

Public API Additions/Changes

New model

• com.mx.path.model.mdx.model.id.v20260428.ResetPassword - new versioned model with username (String) and challenges (List<Challenge>). Unlike the deprecated com.mx.path.model.mdx.model.id.ResetPassword, there is no singular challenge field - only challenges, consistent with newer versioned models.

New accessor method

• IdBaseAccessor.resetPassword20260428(ResetPassword) — new @GatewayAPI/@API-annotated method, returning AccessorResponse<v20260428.ResetPassword>. Default implementation throws AccessorMethodNotImplementedException, matching the pattern of every other optional accessor method. Connector accessors that want to support the new flow must override this method.

New endpoint

• PUT /reset_password (consumes application/vnd.mx.api.v1+json) — added to AuthenticationController, calling gateway().id().resetPassword20260428(...). Always discards any existing session and creates a new one (same session-reset semantics as the old POST /reset_password). Returns 204 No Content on success (empty result) or 202 Accepted with challenges when further input is required.

Downstream Consumer Impact

• No breaking changes. This is a purely additive change:

  • The old endpoints (POST /reset_password, PUT /reset_password/challenges/{challengeId}) continue to work exactly as before.
  • No existing accessor is required to change anything — resetPassword20260428 has a default implementation that throws AccessorMethodNotImplementedException, matching the behavior gateways already have for any unimplemented optional method.
  • Clients that don't call the new PUT /reset_password endpoint are entirely unaffected.

• Behavior change for clients who adopt the new endpoint: PUT /reset_password now creates a brand-new session on every call (discarding any existing session), same as the deprecated POST /reset_password did — this is intentional and matches the old entry-point semantics.

• Migration for accessor implementers: to support the new flow, override resetPassword20260428(ResetPassword) in your IdBaseAccessor subclass. No changes are required to keep using the deprecated flow, but new integrations should implement the new method, since the old flow is deprecated and may be removed in a future major version.

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• ./gradlew check (JDK 21) — full build, all tests, coverage, and static analysis pass
• Targeted controller tests — 34/34 pass, including 3 new v20260428 tests
• Confirmed the annotation-processed gateway proxies regenerate with resetPassword20260428 for id accessor

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works

[meotch]

LGTM, I had to review the new reset_password flow to understand why we are not following the versioned() approach used by authenticate, I see that we are using one endpoint for reset_password flow now, no need to map old endpoints to new endpoints in this instance