feat: implement cancellation of pending message generations

[chenyme]

Summary

Fixes unstable conversation state after manual generation cancellation. Pending user and assistant messages are now finalized by run ID when a generation is canceled, so old turns no longer reappear as loading when the user sends a new message.

Also tightens frontend reconciliation so server-side pending messages are only treated as live streaming messages when their run is actively running or being resumed. This prevents invalid branch state, stale loading indicators, and disappearing interrupted/error branches. Static frontend asset cache headers were also improved for exported Next.js resources.

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/... ./internal/infra/persistence/postgres/conversation/...
• cd backend && go test ./internal/transport/http/conversation/...
• cd backend && go test ./internal/transport/http/...
• cd frontend && pnpm lint
• cd frontend && pnpm build

Screenshots, API examples, or logs

No screenshots required. This change fixes runtime state handling and cache headers.

Configuration, migration, and compatibility notes

No database migration is required.

No API contract changes are introduced. The cancel flow now marks pending generation messages as terminal after cancellation. Frontend static asset cache headers were adjusted for Next.js exported resources and immutable build assets.

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.