feat: SDK update for version 28.0.0

[ChiragAgg5k]

This PR contains updates to the SDK for version 28.0.0.

What's Changed

• Breaking: removed Account.listLogs and the Log, LogList models
• Breaking: removed Client.setDevKey
• Breaking: SDK now targets Appwrite 2.3 (x-appwrite-response-format: 2.3.0)
• Added: Account.createIdTokenSession for native Apple and Google sign-in with IdTokenProvider enum
• Added: Account.createRecoveryOTP and Account.updateRecoveryOTP for code-based password recovery
• Added: Account.createEmailVerificationOTP and Account.updateEmailVerificationOTP
• Added: KAKAO and TIKTOK values to OAuthProvider
• Added: passwordPwned field on User and providerIdToken field on Identity
• Fixed: empty-string required path parameters are rejected instead of sent to the API

[greptile-apps]

Confidence Score: 4/5

The PR appears mergeable, with non-blocking fixes needed for the sign-in examples and authentication test coverage.

Findings

1.  Broken native sign-in example ▶
2.   Session credentials logged ▶
3.  Untested authentication flows ▶

Fix with agent prompt

### Issue 1
docs/examples/java/account/create-id-token-session.md:20
The Java sample passes `0` for `accessTokenExpiry`, but the method expects a boxed `Long`, so the sample does not compile. Changing it to `0L` alone would make the example’s access token immediately expired; the Kotlin sample also supplies zero seconds. Omit the optional expiry or use the provider-reported lifetime.

### Issue 2
docs/examples/java/account/create-id-token-session.md:28
If a developer supplies the access token shown in this example, logging the full returned `Session` can write that credential to Android logs. Log a non-sensitive field such as the session ID instead.

**How this was verified:** The method accepts an access token to store on the session, and `Session.toString()` includes its `providerAccessToken` field before this example passes it to `Log.d`.

```suggestion
        Log.d("Appwrite", result.getId());
```

### Issue 3
library/src/main/java/io/appwrite/services/Account.kt:1693-1698
The new native sign-in and OTP methods have no behavioral HTTP tests. Existing tests cover JSON encoding and Java client setters, but do not exercise these methods’ requests or decoded responses, so authentication regressions could go unnoticed. Add tests of observable requests and results rather than assertions that mirror generated source or version strings.

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!

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR targets Appwrite 2.3 and SDK 28.0.0, adds native ID-token sign-in and OTP account flows, extends provider and model fields, rejects empty required path IDs, and removes the documented legacy APIs.

• The Java sign-in sample needs a valid expiry value and must not log the full session.
• The new authentication flows need observable HTTP-level regression coverage.

_{Reviews (1) · Last reviewed commit: "chore: merge main into dev for the 28.0...."}

[greptile-apps]

Broken native sign-in example The Java sample passes 0 for accessTokenExpiry, but the method expects a boxed Long, so the sample does not compile. Changing it to 0L alone would make the example’s access token immediately expired; the Kotlin sample also supplies zero seconds. Omit the optional expiry or use the provider-reported lifetime.

Prompt To Fix With AI

This is a comment left during a code review.
Path: docs/examples/java/account/create-id-token-session.md
Line: 20

Comment:
**Broken native sign-in example** The Java sample passes `0` for `accessTokenExpiry`, but the method expects a boxed `Long`, so the sample does not compile. Changing it to `0L` alone would make the example’s access token immediately expired; the Kotlin sample also supplies zero seconds. Omit the optional expiry or use the provider-reported lifetime.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Session credentials logged If a developer supplies the access token shown in this example, logging the full returned Session can write that credential to Android logs. Log a non-sensitive field such as the session ID instead.

How this was verified: The method accepts an access token to store on the session, and Session.toString() includes its providerAccessToken field before this example passes it to Log.d.

Suggested change

	Log.d("Appwrite", result.toString());
	Log.d("Appwrite", result.getId());

Prompt To Fix With AI

This is a comment left during a code review.
Path: docs/examples/java/account/create-id-token-session.md
Line: 28

Comment:
**Session credentials logged** If a developer supplies the access token shown in this example, logging the full returned `Session` can write that credential to Android logs. Log a non-sensitive field such as the session ID instead.

**How this was verified:** The method accepts an access token to store on the session, and `Session.toString()` includes its `providerAccessToken` field before this example passes it to `Log.d`.

```suggestion
        Log.d("Appwrite", result.getId());
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Untested authentication flows The new native sign-in and OTP methods have no behavioral HTTP tests. Existing tests cover JSON encoding and Java client setters, but do not exercise these methods’ requests or decoded responses, so authentication regressions could go unnoticed. Add tests of observable requests and results rather than assertions that mirror generated source or version strings.

Prompt To Fix With AI

This is a comment left during a code review.
Path: library/src/main/java/io/appwrite/services/Account.kt
Line: 1693-1698

Comment:
**Untested authentication flows** The new native sign-in and OTP methods have no behavioral HTTP tests. Existing tests cover JSON encoding and Java client setters, but do not exercise these methods’ requests or decoded responses, so authentication regressions could go unnoticed. Add tests of observable requests and results rather than assertions that mirror generated source or version strings.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

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!