deprecate the metadata fields in user update

[brunol95]

In the next API version we introducing a breaking change. Metadata updates will not be accepted via the PATCH /v1/me endpoint. This PR updates the sdk to be backwards compatible with this change

Todos

• update pinned API version

Summary of changes

• Split User.update({ unsafeMetadata, … }) into PATCH /v1/me + PATCH /v1/me/metadata to match the new FAPI shape, preserving replace-semantics via an RFC 7396 merge patch computed locally.
• Added User.updateMetadata (params + JsonObject overload) and the UserApi.updateUserMetadata Retrofit endpoint at the new User.METADATA path.
• Added detekt ReturnCount suppressions on User.update and computeMergePatch
• New tests: MergePatchTest, UserUpdateRoutingTest (covers all routing cases + the staleness regression), UpdateMetadataOverloadTest, plus UpdateMetadataParams cases in UserTest.
• Version bump in gradle.properties.

[coderabbitai]

📝 Walkthrough

Walkthrough

This pull request adds support for updating user metadata with RFC 7396 JSON Merge Patch semantics. The change includes a Clerk API version bump to 1.0.17, a new PATCH /v1/me/metadata endpoint, an RFC 7396-compliant merge-patch algorithm that recursively merges objects and removes keys with null values, a rewritten User.update() method that conditionally routes metadata through the new endpoint, and comprehensive test coverage for serialization, integration, and routing behavior including HTTP interception tests.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 12.24% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Description check	❓ Inconclusive	PR description covers the main objectives and todos, but lacks structured detail on implementation impact and testing strategy.	Add structured sections detailing the migration path for existing users, breaking change documentation, test coverage scope, and any performance or behavioral implications of the merge patch computation.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the main change: deprecating metadata fields in user update. It directly corresponds to the primary objective of preparing the SDK for API deprecation.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

Warning

Review ran into problems

🔥 Problems

Git: Failed to clone repository. Please run the @coderabbitai full review command to re-trigger a full review. If the issue persists, set path_filters to include or exclude specific files.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[swolfand]

@brunol95 made some changes to simplify a bit

[brunol95]

@brunol95 made some changes to simplify a bit

@swolfand thanks! Theres one thing I missed - the merge patch logic for metadata uses the locally cached metadata object but we can't guarantee that it has the latest data. Here's my planned fix.

1. Profile + Metadata update - We refresh the metadata object from the PATCH /V1/ME response before computing the diff.
2. Metadata only update - We refresh the metadata object with a call to ClerkApi.user.getUser() before computing the diff.

[swolfand]

@brunol95 new changes look reasonable to me!