feat: add task deletion

docs/architecture.md

@@ -32,6 +32,7 @@ dnd-kit-ekosystemets aktuella React-adapter. Den ansvarar för:
 - val och visning av ansvarig användare på uppgifter;
 - serverbekräftade statusändringar genom knappar på uppgiftskorten;
 - optimistiska statusflyttar genom drag-and-drop mellan brädans kolumner;
+- bekräftad och serverbekräftad permanent radering av uppgifter;
 - klientnära validering och begripliga felmeddelanden;
 - uppgiftsbrädan med kolumnerna Väntande, Pågående och Klart.
 
@@ -65,6 +66,7 @@ Aktuella endpoints:
 - `POST /api/tasks`
 - `PUT /api/tasks/{taskId}/assignee`
 - `PUT /api/tasks/{taskId}/status`
+- `DELETE /api/tasks/{taskId}`
 
 ### Databas och migreringar
 
@@ -129,6 +131,10 @@ Alla direkta statusövergångar är tillåtna och samma målstatus är idempoten
 frontend aktiv användares id, och backend tilldelar användaren och ändrar status
 i samma transaktion. En befintlig ansvarig byts aldrig av statusoperationen.
 
+Uppgifter raderas fysiskt genom task-repositoryt. Det finns ingen
+mjukraderingsflagga, papperskorg eller återställningsmodell. Radering av en
+uppgift påverkar inte dess ansvariga användare.
+
 ### Aktiv användare
 
 Användarlistan hämtas från backend. Frontend lagrar endast den valda
@@ -156,6 +162,12 @@ backendens fullständiga respons. Status- och tilldelningsanrop delar låsning p
 task-id, så det berörda kortet blockeras utan att resten av brädan låses.
 Drag-and-drop återanvänder backendens befintliga status-API oförändrat.
 
+Radering är serverbekräftad och använder samma låsning per task-id. Kortet och
+bekräftelsedialogen ligger kvar tills backend svarar. Vid `204 No Content`
+tas kortet bort lokalt. Ett `404`-svar tas endast som bekräftelse på att kortet
+redan saknas när felkoden är `TASK_NOT_FOUND`; övriga fel behåller kortet och
+dialogen för ett nytt försök.
+
 ### Teststrategi
 
 Backend har JUnit 5-tester: