feat: add task assignment

docs/architecture.md

@@ -29,6 +29,7 @@ Den ansvarar för:
 - hämtning och presentation av användare och uppgifter;
 - 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;
 - klientnära validering och begripliga felmeddelanden;
 - uppgiftsbrädan med kolumnerna Väntande, Pågående och Klart.
 
@@ -60,6 +61,7 @@ Aktuella endpoints:
 - `POST /api/users`
 - `GET /api/tasks`
 - `POST /api/tasks`
+- `PUT /api/tasks/{taskId}/assignee`
 
 ### Databas och migreringar
 
@@ -77,6 +79,7 @@ Flyway kör migreringarna:
 - `V1__create_users.sql`
 - `V2__create_tasks.sql`
 - `V3__add_task_points.sql`
+- `V4__add_task_assignee.sql`
 
 Hibernate är konfigurerat med `ddl-auto=validate`; Flyway skapar schemat och
 Hibernate validerar entiteterna mot det.
@@ -104,12 +107,19 @@ En uppgift lagras i tabellen `task` med:
 - `description`: valfri beskrivning, högst 500 tecken;
 - `status`: `WAITING`, `IN_PROGRESS` eller `COMPLETED`;
 - `points`: obligatoriskt heltal mellan 1 och 99;
+- `assignee_id`: nullable främmande nyckel till `app_user`;
 - `created_at`: en `Instant`, lagrad som `TIMESTAMP WITH TIME ZONE`.
 
 Status lagras som enumens textvärde genom `EnumType.STRING`. Nya uppgifter får
 alltid status `WAITING`. Poängintervallet skyddas i backend och med en
-databasconstraint. Det finns ingen relation mellan uppgifter och användare;
-alla aktiva användare ser samma uppgiftslista.
+databasconstraint. En uppgift kan vara otilldelad eller referera till exakt en
+ansvarig användare. Relationen hämtas tillsammans med uppgifterna när de listas,
+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.
 
 ### Aktiv användare
 
@@ -124,8 +134,9 @@ lokalt per browser och utgör inte autentisering eller behörighetskontroll.
 ### Felhantering
 
 Backend använder ett litet gemensamt JSON-format med `code` och `message`.
-`ApiExceptionHandler` översätter kända valideringsfel till `400 Bad Request`
-och dubbletter av användarnamn till `409 Conflict`.
+`ApiExceptionHandler` översätter kända valideringsfel till `400 Bad Request`,
+saknade uppgifter eller användare till `404 Not Found` och dubbletter eller
+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