feat: a trash for tickets

Deleting a ticket now sends it to the trash, for whoever opened it or an
admin: it disappears from boards, searches and statistics, cannot change,
and comes back from the ticket page or the trash page for 30 days. After
that it is deleted for good with the usual cascade.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/01-vision-general.md

@@ -20,6 +20,7 @@
 | 🎲 Estimación        | Puntos por ticket (escala 0-1-2-3-5-8-13-21) en la ficha, las tarjetas, las columnas y el backlog; velocidad por sprint y aviso si un sprint planificado supera la media  |
 | 🏃 Sprints           | Iteraciones con fechas y objetivo, una en curso por proyecto, con burndown (tickets o puntos) y traspaso de lo pendiente al cerrar                                        |
 | 📋 Backlog           | Lo pendiente de empezar, en el orden en que se va a coger; se reordena arrastrando y el tablero sigue ese orden                                                           |
+| 🗑️ Papelera          | Borrar un ticket lo manda a la papelera (quien lo abrió o un admin); se recupera durante 30 días y luego se borra del todo                                                |
 | ☑️ En bloque         | Selecciona varios tickets del backlog y cámbiales a la vez estado, persona, sprint, prioridad o etiqueta                                                                  |
 | ⌨️ Atajos y búsqueda | Ctrl/⌘ K o / busca tickets y proyectos de todos tus proyectos; `g b`, `g k`, `g s`, `g r` navegan, `c` crea, `e` edita, `?` los lista                                     |
 | 🗺️ Hoja de ruta      | Las épicas en el tiempo (fecha de inicio y límite), con los sprints y las releases como referencias                                                                       |

docs/03-api.md

@@ -167,6 +167,11 @@ stateDiagram-v2
   actor `system`); el mismo enlace solo vuelve a contar si cambia (una PR fusionada). Proyecto desconocido,
   integración apagada o firma mala responden igual: 403. El secreto vive en MongoDB (`git_integrations`), no en el
   event store.
+- **Papelera**: `trashIssue` / `DELETE /api/issues/{issue}` manda un ticket a la papelera (quien lo abrió o un owner/
+  admin; `IssueTrashedEvent`): desaparece del tablero, las búsquedas, las estadísticas y el progreso, y no se puede
+  cambiar hasta recuperarlo (`restoreIssue` / `POST …/restore`, `IssueRestoredEvent`). `trash(projectId)` /
+  `GET /api/projects/{project}/trash` los lista. A los `TRASH_DAYS` días (30) se borra del todo, con la cascada de
+  siempre: comentarios, enlaces y subtareas de vuelta al primer nivel.
 - **Edición en bloque**: `bulkUpdateIssues` / `POST /api/issues/bulk` aplica el mismo cambio (estado, persona o
   `unassign`, sprint o `noSprint`, release o `noRelease`, prioridad, etiquetas que añadir) a hasta 100 tickets. Cada
   uno pasa por los comandos normales (permisos, flujo, sprints y releases abiertos) y puede negarse sin parar al resto;

docs/07-despliegue.md

@@ -101,6 +101,7 @@ donde los lee Compose.
 | `WEBHOOKS_ALLOW_PRIVATE`                    | `false`                            | Deja que los webhooks salientes llamen a direcciones de esta máquina o de su red privada (apagado, un webhook podría alcanzar servicios internos) |
 | `REMINDERS_ENABLED`                         | `true`                             | Avisa cada hora de los tickets que vencen mañana, hoy o ya han vencido                                                                            |
 | `REMINDERS_TIMEZONE`                        | `Europe/Madrid`                    | Zona horaria en la que cambia el día para los recordatorios                                                                                       |
+| `TRASH_DAYS`                                | `30`                               | Días que un ticket pasa en la papelera antes de borrarse del todo                                                                                 |
 
 La web no tiene configuración de entorno: llama a la API en su mismo origen (`/api`, `/graphql`).