feat: soft-delete mappings to .trash/

[kyuchia]

Deleting a mapping from Trash now also removes it from the user's cress-mappings repo when logged in — previously it only deleted the local PouchDB copy, leaving the GitHub file orphaned (found 2026-06-18). Part of #139.

Changes

• MappingStorage.ts: add deleteRemoteOnly (remote-only delete). It fetches the blob sha from the backend on cache miss, so cross-session deletes work even when the file wasn't opened this session.
• Dashboard.ts: deleteFileEntry now calls deleteRemoteOnly, then removes the local doc by id. All three permanent-delete paths (Delete, Empty Trash, 30-day cleanup) route through it. Move-to-Trash / Put Back deliberately untouched — files stay recoverable while in Trash.
• MappingStorage.ts: moveRemote now retries on 409 with backoff (re-probes the dest sha) to handle GitHub's eventual consistency on rapid consecutive trash moves. Mitigates but doesn't fully eliminate the concurrent-move race; full fix (serializing moves) tracked as follow-up.
• Minor: removed stale issue/meeting refs from githubStorage comments.

Testing (manual, PAT in localStorage)

• Logged in, remote file exists → deleted on GitHub (verified via commit; cross-session, so the sha fallback ran)
• Logged in, remote file missing → 404, no delete, no error
• Logged out → no GitHub request

Notes

• Base feat/github-storage; merge after feat: save and load mapping files to/from GitHub #140.
• No GitHub-side soft delete (tracked in feat: make remote (GitHub) deletes recoverable #142), Empty Trash / 30-day cleanup removes from the remote immediately, no recoverable buffer.

[kyuchia]

Update (approach changed): Following the 6/18 meeting decision that the GitHub remote should never be permanently deleted, this PR no longer deletes the remote file. It now soft-deletes by moving the mapping to a .trash/ prefix, and restores by moving it back. Permanent deletes (Empty Trash / 30-day cleanup) only clear local state. The .trash/ copy stays recoverable.

The original description below describes the earlier delete-outright approach, which has been reversed.

What's in the latest commits:

• trashRemote / restoreRemote move files to/from .trash/ via copy-then-delete (the contents API has no rename).
• Sync is centralized in moveToFolder, so both the button and drag-and-drop paths are handled.
• contentsUrl encodes path segments individually so .trash/foo.csv stays a real subdir.
• moveRemote retries on conflict to tolerate eventual consistency when re-trashing a just-restored file.

Verified end-to-end: save → trash → .trash/; restore → back to top level; permanent delete → local cleared, .trash/ copy retained.

[kyuchia]

Added 409-retry in moveRemote for GitHub's eventual consistency on rapid consecutive trash moves, where a write can hit a stale sha.

This mitigates but doesn't fully eliminate the race. The root cause is concurrent fire-and-forget moves from moveToFolder; a full fix (serializing moves) is tracked as follow-up.