Feature request: Trash/recover view for deleted tasks + prune policy for soft-deleted data

[kzssc]

Problem

Deleting a task in Vikunja is a soft delete under the hood — the tasks table has a deleted_at column, and the row (along with related task_reminders, task_buckets, comments, attachments, etc.) is simply hidden from the API/UI rather than removed.

However, there's currently no way for a user to see or restore what they've deleted, and no automatic (or manual) mechanism to purge old soft-deleted rows:

• There's no "Trash" view in the UI/API to list or recover recently deleted tasks after the initial "Undo" toast expires — once that toast is dismissed, the task is gone from the user's perspective even though it still exists in the database.
• There's no retention/prune job (cron, CLI command, or config option) that ever hard-deletes old soft-deleted rows. In practice this means soft-deleted tasks — and their related reminders, bucket assignments, etc. — accumulate in the database indefinitely with no way to clean them up short of manual SQL.

I noticed this while poking around a self-hosted instance: several test tasks deleted weeks ago were still fully present in Postgres with deleted_at set, still joined to task_reminders rows, etc.

Suggestion

Two related, separable features:

1. Trash / recover UI: A "Trash" section (similar to what many apps offer) listing soft-deleted tasks for a user's projects, with the ability to restore a task or delete it permanently. This turns the existing soft-delete into an actual safety net beyond the few-second "Undo" toast.
2. Prune / retention job: A way to permanently purge soft-deleted tasks (and their orphaned related rows — reminders, bucket assignments, etc.) after a configurable retention period (e.g. service.taskretentionperiod or similar), run either as a periodic background job or exposed as a vikunja repair/CLI subcommand an admin can run manually. This keeps the database from growing unbounded with data nobody can ever see or act on again.