Add soft-delete (trash/recycle bin) instead of permanent image deletion

**Problem**
Currently deleting an image (single or bulk) removes it — and its DB rows/embeddings — permanently with no way to recover. A single misclick in bulk-select mode can wipe irreplaceable photos with zero undo path.

**Proposed solution**
- Add a `deleted_at` (nullable) column to the images table instead of hard-deleting the row on first delete
- "Trash" view in the UI showing soft-deleted images, with Restore / Delete Forever actions
- Auto-purge (hard delete) items from trash after N days (configurable), which is where the existing orphaned-rows cleanup from #1405 would actually run
- Embeddings/semantic_labels stay untouched until final purge, so restore is cheap

**Why this matters**
Photo apps (Google Photos, Apple Photos) all have this as a baseline safety feature. PictoPy currently has none, which is risky for a local-first tool where there's no cloud backup.

Happy to pick this up — I've worked on the DB layer before (album/faces unit tests, PR #1342) and can pair the schema change with test coverage.

Start with the DB layer and the existing album/faces unit tests referenced in the issue, then trace the single- and bulk-delete flows and the image UI. Define the schema, trash, restore, permanent deletion, and configurable purge behavior before implementation. Done means deleted images can be restored, final deletion removes associated data, and the flows have test coverage.

Written by the indexing model from the issue text.