feat(chats): delete a conversation from the chat 3-dot menu

[sathyaprakash000]

What does this PR do?

Adds a way to delete a chat from inside the conversation itself. Clearing a chat previously meant going into the database by hand.

The chat window's 3-dot menu (alongside Contact info / Refresh / Export chat) gains two admin-only actions:

• Delete chat history — removes every chat_history row, its message_reactions, and the conversation_reads marker for one (wa_number, contact_number) pair, and unlinks the conversation's stored media. The saved contact (name, tags, custom fields, assignment) is kept, so the chat simply reopens empty and future inbound messages land normally.
• Delete contact & chat — the same sweep, plus the contacts row.

Both go through the repo's existing DeleteConfirmModal. On success ChatsPage unselects the chat and refetches the contact list.

Backed by a new admin-gated DELETE /api/chat-history?waNumber=&contactNumber=[&withContact=1].

Notes for a reviewer:

• Ordering is deliberate. The row deletes run in one transaction; media paths are SELECTed inside it but unlinked only after the commit. A rollback can undo a DELETE, but nothing can undo an unlink — deleting files first would leave unreachable-media rows in a chat that still exists, which is strictly worse than the reverse failure (an orphan blob on disk). File cleanup is best-effort and never fails the request.
• Path containment. Unlinking goes through a new resolveInMediaDir guard, mirroring the containment the media read route already applies, so a bad media_storage_path in the DB can never reach outside MEDIA_DIR.
• Media is safe to hard-delete. persistOutboundMedia writes a per-message copy even when the source is a shared Media Library object, so removing a conversation's files cannot orphan the library.
• Role gate, not assertContactAccess. This is a semantic choice, not just a stricter check: "is this your conversation?" is the right question for reading and replying, but the wrong one for erasing — the person most attached to a chat is exactly the one you don't want quietly deleting it. The frontend menu items are hidden for non-admins to mirror the server gate.
• Scope. deals and automation_executions are deliberately left intact — they're CRM history, not chat history.
• Every deletion is recorded via auditLog (chat.delete_history / chat.delete_with_contact) with the affected counts.

Related issue

None — raised directly as a product request.

Type of change

• 🐛 Bug fix
• ✨ New feature
• ♻️ Refactor
• 📝 Documentation
• 🔧 Chore / tooling

How was this tested?

• npx vitest run in frontend/ — 51 passed (3 files).
• node --test test/ in backend/ — 20 passed.
• npx vite build — clean.
• node --check on the modified route.
• Confirmed against db/migrations/ that all five tables touched (chat_history, message_reactions, conversation_reads, contacts, user_audit_log) already exist, so no migration is needed. The same set is precedented by the existing /contacts/change-number route, which updates exactly these tables.

Not run: the Playwright half of npm test (test:e2e), which needs a running app; and I could not smoke-test the SQL against a live database — the running forgechat-db container on this host belongs to a different Forgechat app (Prisma public.* schema), not this repo's coexistence schema. Worth a manual pass on a real conversation with media before merge.

Checklist

• Branch is up to date with upstream/main.
• The change is focused on a single concern.
• Frontend tests pass (npm test in frontend/) and tests were added where relevant.
• Any schema change is a new numbered migration in db/migrations/. (N/A — no schema change.)
• Commits follow Conventional Commits and are signed off (git commit -s, DCO).
• Docs updated, including a ## [Unreleased] entry in CHANGELOG.md if behaviour changed.
• No secrets, .env files, or generated artifacts are committed.

🤖 Generated with Claude Code