[BUG] /export silently overwrites existing files without confirmation

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information

Bug Description

When /export <filename> is run with a filename that already exists on disk, the existing file is silently overwritten with no warning, no confirmation prompt, and no auto-rename. The previous export is permanently lost.

This was previously reported as #37595, which was auto-closed as stale (the closing bot itself suggests opening a new issue and referencing the original — doing so here). Related: #15873 (also closed).

Steps to Reproduce

1. Run /export session — creates session.txt
2. Continue conversation, accumulate new content
3. Run /export session again
4. Original session.txt is silently replaced. No prompt, no warning.

Expected Behavior

/export should not destroy existing files without user consent. At minimum one of:

• Confirmation prompt: File already exists. Overwrite? (y/N)
• Auto-increment: session_2.txt, session_3.txt, ...
• Refuse with clear error: File exists, use a different name or pass --force
• Optional --force/-f flag for users who want the current overwrite behavior explicitly

The confirmation prompt is the most consistent with the rest of Claude Code's behavior around destructive actions.

Actual Behavior

File is silently overwritten. No prompt, no warning, no notice in the export confirmation message. Previous export is unrecoverable unless the user has it in version control or a backup.

Impact

Users who name exports consistently (e.g., per-topic, per-day) can lose hours of saved conversation history through a single keystroke with no opportunity to cancel. Standard CLI tools (cp, mv with -i, most editors, every GUI file dialog) have prompted before overwrite for decades — the export command should match that baseline.

Environment

• OpenBSD 7.9
• Claude Code (current)

References

• #37595 — original bug report, auto-closed as stale
• #15873 — related feature request for timestamped filenames, also closed