feat: add task status transitions

docs/architecture.md

@@ -30,6 +30,7 @@ Den ansvarar för:
 - lokalt val av aktiv användare;
 - formulär för att skapa användare och uppgifter;
 - val och visning av ansvarig användare på uppgifter;
+- serverbekräftade statusändringar genom knappar på uppgiftskorten;
 - klientnära validering och begripliga felmeddelanden;
 - uppgiftsbrädan med kolumnerna Väntande, Pågående och Klart.
 
@@ -62,6 +63,7 @@ Aktuella endpoints:
 - `GET /api/tasks`
 - `POST /api/tasks`
 - `PUT /api/tasks/{taskId}/assignee`
+- `PUT /api/tasks/{taskId}/status`
 
 ### Databas och migreringar
 
@@ -117,9 +119,14 @@ ansvarig användare. Relationen hämtas tillsammans med uppgifterna när de list
 så API-responsen kan innehålla ansvarigs `id` och `name` utan separata
 frontend-anrop. Alla aktiva användare ser samma uppgiftslista.
 
-Ansvarig är valfri vid skapande. Endast väntande uppgifter kan få ändrad
-ansvarig genom det särskilda tilldelnings-API:t. Tilldelning ändrar aldrig
-uppgiftens status.
+Ansvarig är valfri vid skapande. Tilldelnings-API:t kan tilldela eller byta
+ansvarig i samtliga statusar. Ansvarig kan tas bort i `WAITING` och `COMPLETED`,
+men inte i `IN_PROGRESS`. Tilldelning ändrar aldrig uppgiftens status.
+
+Alla direkta statusövergångar är tillåtna och samma målstatus är idempotent.
+`IN_PROGRESS` kräver en ansvarig. När en otilldelad uppgift påbörjas skickar
+frontend aktiv användares id, och backend tilldelar användaren och ändrar status
+i samma transaktion. En befintlig ansvarig byts aldrig av statusoperationen.
 
 ### Aktiv användare
 
@@ -140,7 +147,8 @@ otillåtna tilldelningsändringar till `409 Conflict`.
 
 Frontend skiljer mellan fel vid hämtning och skapande. Hämtfel kan
 återförsökas. Formulärfel visas nära formuläret och inmatningen behålls vid
-misslyckade API-anrop.
+misslyckade API-anrop. Status- och tilldelningsfel visas lokalt på berört kort;
+kortet uppdateras först med backendens bekräftade respons.
 
 ### Teststrategi