callCompletionApi does not handle rejected async onFinish callbacks

Finding: In an external report on vercel/ai, callCompletionApi is said to leave an async onFinish rejection unhandled when run with ai@7.0.137 and upstream commit ba05943 on Node.js v26.7.0, macOS. The reporter says onError and setError are not called, so the failure does not go through the normal completion error path (https://github.com/vercel/ai/issues/22698). Reported setup: a mocked fetch returns a text-stream response of 'answer', and the onFinish callback is an async function that throws an error. The reporter's script records process unhandledRejection events and also captures what onError and setError receive. The reporter says both tested builds emit one unhandled rejection containing the fixture error, while onError and setError receive nothing, and the final assertions fail. The issue does not give a separate exact error string beyond the fixture error message 'Could not persist completion'. Reported impact: completion hooks that use the shared helper can lose failures from async persistence done in onFinish. The reporter notes that TypeScript allows async functions where a void-returning callback type is expected, although the current declaration does not explicitly promise awaiting. Proposed direction, unverified: the reporter suggests awaiting onFinish(prompt, result) inside the existing try block, explicitly allowing PromiseLike<void> in the callback type, and adding tests for sync success, async success, sync throw and async rejection. The proposal would also keep the current-request checks when a newer completion starts. The reporter labels this as untested, and the supplied context shows no maintainer confirmation, fix commit or release. Limitations: this is a single external report using mocked fetch, with no comments in the supplied context. It has not been reproduced by KFA, and the cause is the reporter's analysis rather than maintainer-confirmed. Related issue #22576 is described by the reporter as a separate Svelte StructuredObject case and is not evidence for this one. No safe workaround is source-backed in the issue itself.