refactor: enhance message handling and billing logic

[chenyme]

Summary

Fix conversation streaming failure handling so failed turns keep a stable server-backed message chain.

When a streaming request fails after the backend has already created the user/assistant message pair, the stream error now returns those real message IDs even if no visible content was produced. Non-billable failure results release the reserved usage balance instead of recording usage. The frontend reconciles pending messages with server terminal states, avoids losing buffered stream text on failure, and only exposes retry/edit/continue actions for persisted messages that can actually be addressed by the backend.

Change type

• Bug fix
• Feature
• Documentation
• Refactor
• Configuration / deployment
• Security hardening
• Other

Affected areas

• Frontend / UI
• Backend / API
• Authentication / authorization
• Conversations / streaming
• Files / RAG / extraction
• Model routing / providers
• MCP / tools
• Billing / payments
• Admin console
• Deployment / Docker / configuration
• Documentation

Verification

• cd backend && go test ./internal/application/conversation/...
• cd backend && go test ./internal/transport/http/conversation/...
• cd frontend && pnpm lint
• git diff --check

Screenshots, API examples, or logs

No screenshots. This is a streaming/message-chain behavior fix.

Configuration, migration, and compatibility notes

No database migration, environment variable, Docker, or public configuration changes.

Streaming error events may now include data.userMessage and data.assistantMessage for non-billable failed turns when the backend already created the message pair. This keeps frontend branch reconciliation on real server message IDs and does not charge usage for no-output failures.

Documentation

• Documentation is not needed for this change.
• Documentation was updated.
• Documentation still needs to be updated.

Security and privacy

• No secrets, tokens, credentials, local config, or personal data are included.
• User data access remains scoped by authenticated user context unless an admin-only path explicitly requires broader access.
• Security-sensitive behavior was reviewed, including authentication, authorization, provider routing, file processing, billing, and admin APIs where relevant.

Checklist

• I searched existing issues and pull requests.
• Changes are focused and do not include unrelated refactors.
• Tests or static verification were run where practical.
• User-facing behavior, deployment steps, API contracts, or configuration changes are documented.
• Generated artifacts are included only when this project explicitly requires them.
• Caches, build output, .pyc files, .env files, and local storage data are not committed.