feat: SDK update for version 25.2.0

[ArnabChatterjee20k]

This PR contains updates to the SDK for version 25.2.0.

What's Changed

• Added: Realtime connections now send an x-appwrite-jwt header for authentication.
• Added: Forwarded impersonateUserId on avatars and storage file requests.

[greptile-apps]

Greptile Summary

This SDK update to v25.2.0 adds JWT authentication for Realtime WebSocket connections, forwards impersonateUserId on avatar and storage file requests, deprecates Databases transaction methods in favour of TablesDB, and applies a cosmetic path-string wrapping refactor across all services. Both new runtime features are broken by config map key case mismatches that cause the lookups to silently return null.

• Realtime JWT header: Realtime.createSocket() reads client.config[\"jwt\"] but Client.setJWT() stores the value at config[\"jWT\"] — the x-appwrite-jwt WebSocket header is never sent.
• ImpersonateUserId forwarding: Avatars.kt and Storage.kt read client.config[\"impersonateuserid\"] (all lowercase) while setImpersonateUserId() stores at config[\"impersonateUserId\"] (camelCase) — the query parameter is always null for every affected endpoint.
• The @Deprecated annotations added to Databases transaction methods and the cosmetic apiPath wrapping refactor are correct and safe.

Confidence Score: 3/5

Both headline features are silently non-functional due to config key casing mismatches; existing non-impersonated API surface is unaffected.

JWT auth on Realtime sockets and impersonateUserId forwarding each fail because the config map is read with a different key casing than the one used when storing the value, making both advertised additions dead code at runtime.

Realtime.kt (JWT lookup), Avatars.kt and Storage.kt (impersonateUserId lookup), and Client.kt (source-of-truth for stored key names).

Important Files Changed

Filename	Overview
library/src/main/java/io/appwrite/services/Realtime.kt	Adds x-appwrite-jwt header to WebSocket handshake, but reads config["jwt"] while Client.setJWT() stores at config["jWT"] — header is never actually sent
library/src/main/java/io/appwrite/services/Avatars.kt	Forwards impersonateuserid as a query param across all avatar endpoints, but reads config["impersonateuserid"] while setImpersonateUserId() stores at config["impersonateUserId"] — param is always null
library/src/main/java/io/appwrite/services/Storage.kt	Forwards impersonateuserid on download/preview/view endpoints with the same config key mismatch as Avatars.kt — impersonation parameter is never populated
library/src/main/java/io/appwrite/Client.kt	Version bump to 25.2.0, docstring trimming for impersonation methods, ping endpoint switches from content-type to accept header — functional changes are safe
library/src/main/java/io/appwrite/services/Account.kt	Mass cosmetic refactor wrapping apiPath string literals in parentheses across all methods — no logic changes, purely style
library/src/main/java/io/appwrite/services/Databases.kt	Adds @deprecated annotations pointing to TablesDB on all transaction/operation methods; path wrapping refactor applied — no logic changes
library/src/main/java/io/appwrite/services/TablesDB.kt	Path wrapping cosmetic refactor only — no logic changes
CHANGELOG.md	Adds 25.2.0 entry for JWT Realtime header and impersonateUserId forwarding — both advertised features are broken due to config key case mismatches in the implementation

_{Reviews (3): Last reviewed commit: "chore: update Android SDK to 25.2.0" | Re-trigger Greptile}

[greptile-apps]

Both password fields show the same literal value

After this change both password and oldPassword are set to the plain string "password". The previous oldPassword = "<OLD_PASSWORD>" placeholder made the distinction between the two arguments visually obvious. Using identical string literals here makes it easy for a reader to copy the snippet and inadvertently pass the same value for both, which the server will accept as a valid (though semantically wrong) request. Consider using distinct placeholder strings — e.g. "newPassword" / "oldPassword" — to communicate intent.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!