[Code Health]: Replace public any types with safer SDK surface types

[Fermionic-Lyu]

Summary

Several public SDK surfaces still use any for request/response shapes even though the SDK advertises full TypeScript support and imports shared schema types. This weakens editor help and allows docs/API drift to slip through.

Validation

Partially valid. The any usage is confirmed in public module code on main@d7c4cf74cda6c6a80948cfa6d8137f9d0c0dbdf7; changing types should be scoped to avoid accidental breaking changes.

Relevant Code

• src/modules/ai.ts:108 - chat.completions.create returns Promise<any>.
• src/modules/ai.ts:192 - parseSSEStream yields AsyncIterableIterator<any>.
• src/modules/ai.ts:309 - embeddings.create returns Promise<any>.
• src/modules/ai.ts:360 - images.generate returns Promise<any>.
• src/modules/functions.ts:8 - FunctionInvokeOptions.body is typed as any.
• src/modules/functions.ts:93 - invoke<T = any> defaults the public response type to any.
• src/lib/http-client.ts:681, src/lib/http-client.ts:686, and src/lib/http-client.ts:691 - public HTTP body helpers accept any.

Proposed Solution

Replace public any types with named request/response types where possible. For intentionally generic request bodies, prefer unknown, JsonValue, or a documented generic parameter.

Acceptance Criteria

• AI public methods expose useful TypeScript return types that match runtime behavior.
• Functions/body helpers avoid any where a safer type is practical.
• Existing typecheck and unit tests continue to pass.