在流式请求中，client_gone 导致 New API 计费为 0，但上游已正常扣费，客户端收到了完整响应

Deployment source Repository release / official image (self-hosted) ### Your current newapi version v1.0.0-rc.25 ### Submission Checks - [x] Non-duplicate issue: I have searched existing Issues and confirmed there are no similar issues. - [x] Read this first: I have fully read the section above, reviewed the docs at https://docs.newapi.ai/ and the project README, and asked AI first, confirming this is not a usage, configuration, or integration question. - [x] Supported version: I have provided an exact version, commit, or image tag (not latest or unknown) and confirmed that the issue reproduces on an unmodified, supported version from this repository. - [x] Not a third-party service: I confirm that this issue is not exclusive to a third-party hosting site, relay, API service, or fork that has not been verified against the unmodified repository. Third-party instance issues must be reported to their operator. - [x] Issue attribution: I have provided evidence that distinguishes the client, new-api, and upstream layers. For relay issues, I compared equivalent redacted requests sent directly upstream and through new-api, confirming that new-api introduces or changes the error rather than merely forwarding the upstream error unchanged. - [x] Channel and protocol boundary: I confirm that the issue is not caused by a Coding Plan service, reverse-engineered channel, third-party API wrapper, Codex reverse-proxy endpoint, or behavior specific to the Codex API. If first observed through such an interface, I have reproduced it using a standard API protocol supported by this repository. - [x] Maintainer time: I understand that maintainers have limited time and issues that do not follow this template may be ignored or closed directly. ### Issue Description When a streaming request (stream: true) has successfully returned the first character to the client, the connection is broken due to network fluctuations, client timeout, or user cancellation, New API records client_gone and immediately cancels the upstream request (terminates the read from Sub2API). Because the upstream response is interrupted, New API cannot obtain the final usage information and marks the request as failed, refunds the pre-deductible quota, so the consumption record shows a fee of $0 and 0 tokens. However, Sub2API has fully processed the request, generated a complete response, and charged according to actual usage (which can be verified from Sub2API's back-office billing). The client usually receives most or all of the content before the connection is broken, resulting in the user believing that the service has been provided normally, while New API shows no charge, resulting in an inconsistent account. Impact - Difficulty in reconciling financial accounts: users have not been charged in New API, but Sub2API has actually spent money, requiring manual verification. - Impact on streaming long-response scenarios, occurring at a high frequency in environments with unstable networks. - As can be seen from the screenshot, multiple requests in New API show $0, while the client shows positive tokens and fees. Frequency of occurrence [Please fill in: for example, "in streaming requests with a response length exceeding 500 tokens, this occurs about 5% to 10% of the time"] Evidence that the problem is at the New API layer 1. Direct upstream comparison: send the same request directly to Sub2API (bypassing New API), using the same client, Sub2API records usage and charges after complete processing, and the back-office billing can be checked. 2. After New API: under the same conditions, New API logs client_gone, the upstream request is canceled, and the consumption record shows $0, and there is no usage information in the relay log. 3. Client-side evidence: the screenshot shows that the client successfully displays the token number and fee for each request, while the New API list shows multiple requests with a fee of $0 at the same time point.