fix(gdpr): explicit radering av ai_corrections/scan_jobs + S3-bilder vid DELETE /v1/me

- DELETE /v1/me soft-deletar users, så users-cascade fyrar aldrig.
- Samlar distinkta bildnycklar från ai_corrections, ai_training_bank och
  scan_jobs och raderar dem via storage.deleteObject innan DB-radering.
- S3-fel loggas och avbryter inte raderingen.
- Raderar explicit ai_corrections (ai_training_bank cascadar) och scan_jobs.
- Lägger till deleteObject i StorageService (mock + AWS/DeleteObjectCommand).
- Uppdaterar docs/28-lärande-loop.md med faktisk mekanism och retention.
- Tester: verifierar noll rader kvar och storage.deleteObject-anrop.

Relaterat: skiva-1-fixrunda, blockerande GDPR-hål.

docs/28-lärande-loop.md

@@ -96,23 +96,40 @@ användarens samtycke inte påverkar redan bankade data.
   användaren återkallar samtycke — då raderas endast rader där
   `consentSnapshot.anonymized_improvement = "denied"` (i praktiken
   exporteras de aldrig).
-- Bilder i lagring: följer samma regler som `imageS3Key` — sparas så
-  länge kontot finns, raderas vid kontoradering.
+- **Träningsbilder (`image_s3_key`)**: raderas senast **90 dagar efter
+  att de bankats** till `ai_training_bank`, om användaren inte aktivt
+  valt att spara sina bidrag längre. För användare som samtycker till
+  långtidslagring (t.ex. för att förbättra modellen över tid) kan
+  bilderna behållas så länge kontot finns, men aldrig längre än vad
+  användaren samtyckt till. Vid återkallat `image_training`-samtycke
+  raderas bilderna inom 30 dagar.
+- Bilder som endast ingår i råa `scan_jobs` (inte bankade som
+  träningsdata): raderas enligt samma 90-dagarspolicy eller när skanningen
+  tas bort, beroende på vilket som inträffar först.
 
 ## GDPR / kontoradering
 
-Vid kontoradering (eller rätten att bli glömd):
+`DELETE /v1/me` soft-deletar (anonymiserar) `users`-raden för att
+bevara referensintegritet i aggregat. Därför fyras **inte** FK-cascade
+från `users` till `ai_corrections` eller `scan_jobs`. Istället sker
+raderingen explicit:
 
-- `users` → cascade delete → `ai_corrections` försvinner (FK `ON DELETE CASCADE`).
-- `ai_corrections` → cascade delete → `ai_training_bank` försvinner (FK `ON DELETE CASCADE`).
-- Bilder som refereras av `ai_corrections.imageS3Key` och
-  `ai_training_bank.imageS3Key` måste raderas från lagring. Detta görs av
-  en GDPR-raderingsprocessor (se Del 12) som läser bildnycklarna innan
-  användarposten tas bort.
+1. Saml alla distinkta bildnycklar för användaren:
+   - `ai_corrections.image_s3_key`
+   - `ai_training_bank.image_s3_key` (via join mot `ai_corrections`)
+   - `scan_jobs.s3_keys`
+2. Radera varje nyckel i objektlagring med `storage.deleteObject`.
+   S3-fel loggas och påverkar inte fortsatt radering.
+3. Radera `ai_corrections` för `userId`. `ai_training_bank` försvinner
+   automatiskt via `correction_id ON DELETE CASCADE`.
+4. Radera `scan_jobs` för `userId` (även denna cascade fyrar inte vid
+   soft-delete).
+5. Fortsätt med hård radering av övrig persondata och anonymisera
+   användarposten.
 
 Verifiera alltid att kontoraderingstestet kontrollerar både
-`ai_corrections`, `ai_training_bank` och att inga överblivna bildnycklar
-finns kvar i S3/mock-lagringen.
+`ai_corrections`, `ai_training_bank`, `scan_jobs` och att inga
+överblivna bildnycklar finns kvar i S3/mock-lagringen.
 
 ## Inget PII i analytics