feat: support optional file cleanup when deleting conversations

[chenyme]

Summary

Add an optional file cleanup flow when deleting conversations or deleting projects with conversations. Users can choose to also delete files attached to deleted conversations, while files still referenced by other active conversations are kept.

The backend now re-checks file references before deleting file objects, returns the deleted file count and latest storage quota, and updates Swagger. The frontend adds delete-file checkboxes in conversation/project delete dialogs and refreshes the Files page through a shared file-library invalidation event.

Change type

• Feature
• Bug fix
• 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 ./...
• cd backend && make swagger
• cd frontend && pnpm lint
• cd frontend && pnpm build

Screenshots, API examples, or logs

Not included. UI changes are limited to delete confirmation options.

Configuration, migration, and compatibility notes

Configuration changes: None.

API changes:

• DELETE /api/v1/conversations/:id supports delete_files=true.
• DELETE /api/v1/conversation-projects/:id supports delete_files=true when deleting project conversations.
• Delete responses include deletedFileCount and may include latest storage quota.

Database migrations: None.

Deployment changes: None.

Backward compatibility: Existing delete behavior is unchanged unless delete_files=true is provided. Files referenced by other active conversations are not deleted.

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.