feat:compatible with Pageindex SDK

[saccharin98]

No description provided.

[saccharin98]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[saccharin98]

Codex review

I found two cloud-compatibility issues that are worth fixing before merge. The local tests pass (78 passed, 2 skipped), but both cases can still fail against the real API because they involve response/status semantics and a server-side streaming flag.

1. chat_completions(..., stream_metadata=True) only changes the local parser; it is never included in the request payload. The existing CloudBackend.query_stream sends stream_metadata=True when it wants metadata chunks, so this compatibility method can return raw chunks without the API ever being asked to emit metadata/citation/tool fields. Please pass the flag through when requested and update the payload assertion test accordingly.

2. delete_document() returns response.json() and _request() only accepts status code 200. A successful REST delete commonly comes back as 204 or as 200 with an empty body; in either case this compatibility method raises instead of reporting success. The existing CloudBackend.delete_document intentionally ignores the body, so this should probably accept 2xx/empty responses and return an empty dict or otherwise special-case deletes.

[saccharin98]

Codex review follow-up correction

I rechecked this PR against the old SDK implementation in pageindex_sdk-main. The two points I raised above should not be treated as blocking compatibility issues for this PR:

1. The old SDK also does not send stream_metadata in the chat/completions request payload; it only uses that flag to choose whether to parse streamed chunks as raw JSON or text. So the PR is matching the old SDK contract here.

2. The old SDK delete_document() also expects status code 200 and returns response.json(). So the current compatibility layer is preserving the old behavior rather than introducing a new delete-response regression.

Those may still be future hardening opportunities if the cloud API contract changes, but they are not valid request-changes findings for this compatibility PR. Apologies for the earlier over-broad review.