feat: Android SDK update for version 24.1.0

[ChiragAgg5k]

This PR contains updates to the SDK for version 24.1.0.

What's Changed

• Added: Added setCookie() method to Client for forwarding incoming Cookie headers in server-side runtimes
• Added: Added Fusionauth, Keycloak, and Kick OAuth providers to OAuthProvider enum
• Updated: Updated X-Appwrite-Response-Format header to 1.9.4

[greptile-apps]

Greptile Summary

This PR updates the Android SDK to version 24.1.0, adding three new OAuth providers (fusionauth, keycloak, kick), a new setCookie() helper on Client, and bumping the x-appwrite-response-format header to 1.9.4. The CI workflow is also modernised with updated action versions.

• New OAuth providers: FUSIONAUTH, KEYCLOAK, and KICK are added to the OAuthProvider enum in correct alphabetical order with proper @SerializedName annotations, and the KDoc for both createOAuth2Session overloads in Account.kt is updated to match.
• setCookie() method: Adds a raw "cookie" header to all outgoing requests; the KDoc frames this as a server-side forwarding helper, but the Android SDK already manages cookies via a ListenableCookieJar backed by SharedPreferencesCookieStore — see inline comment for details.
• CI update: actions/checkout and actions/setup-java are bumped to newer major versions; the required distribution: temurin parameter is correctly added.

Confidence Score: 4/5

Safe to merge; the only item worth confirming is whether setCookie() is intentionally included in the Android client SDK given its existing cookie jar.

All version bumps, enum additions, and doc updates are consistent and correct. The one area worth a second look is setCookie() in Client.kt: the Android SDK already manages cookies through ListenableCookieJar/CookiePolicy.ACCEPT_ALL, so injecting a raw cookie header alongside jar-managed cookies could produce conflicting or duplicate Cookie headers depending on OkHttp's merge behaviour.

library/src/main/java/io/appwrite/Client.kt — specifically the new setCookie() method and its interaction with the existing cookie jar setup.

Important Files Changed

Filename	Overview
library/src/main/java/io/appwrite/Client.kt	Adds setCookie() method and bumps SDK/response-format versions; the new method sets a raw cookie header which may interact unexpectedly with the existing ListenableCookieJar
library/src/main/java/io/appwrite/enums/OAuthProvider.kt	Adds FUSIONAUTH, KEYCLOAK, and KICK OAuth providers in correct alphabetical order with proper @SerializedName annotations
.github/workflows/publish.yml	Updates actions/checkout and actions/setup-java to newer major versions; adds required distribution: temurin for the updated setup-java action
library/src/main/java/io/appwrite/services/Account.kt	KDoc comments updated in two createOAuth2Session overloads to reflect the new OAuth providers; no logic changes
CHANGELOG.md	New 24.1.0 section added accurately describing the setCookie addition, new OAuth providers, and updated response-format header version
README.md	Version references updated from 24.0.0 to 24.1.0 and API version badge bumped from 1.9.2 to 1.9.4

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

[greptile-apps]

setCookie may conflict with the existing cookie jar

The Client is already configured with a ListenableCookieJar (CookiePolicy.ACCEPT_ALL) backed by SharedPreferencesCookieStore. When OkHttp's BridgeInterceptor executes, it adds cookies from the jar to the outgoing Cookie header. Injecting a second raw "cookie" header via addHeader may result in duplicate or merged Cookie headers whose precedence depends on OkHttp internals, potentially overwriting persisted session cookies or confusing the server.

The KDoc states this method is "Used by SDKs that forward an incoming Cookie header in server-side runtimes", but the Android SDK is a client-side SDK that already manages cookies automatically. Callers on Android who invoke this method expecting server-forwarding behaviour may instead see unexpected cookie collisions with the shared-preferences store.

[ChiragAgg5k]

Closing — changes not substantial enough to warrant a release.