docs: update documentation to OKF v0.1 format

docs/api/uploads.md

@@ -3,7 +3,7 @@ type: api
 title: Uploads Endpoints
 description: Admin-only multipart upload endpoints for site logos, category icons, and challenge files.
 tags: [api, uploads, multipart, admin]
-timestamp: 2026-07-22T13:05:30Z
+timestamp: 2026-07-22T19:18:00Z
 ---
 
 # Endpoints
@@ -37,6 +37,19 @@ valid admin session and the standard CSRF cookie/header pair.
 * An accepted logo keeps its sanitized filename, is written directly under
   `UPLOAD_DIR`, and returns `{ publicUrl, originalFilename }`, with `publicUrl`
   in the form `/uploads/{safeFilename}`.
+* Category icons are decoded with Sharp and normalized to a 128-by-128 PNG.
+  When `categoryId` is supplied, the file is written to
+  `UPLOAD_DIR/icons/{categoryId}.png` (overwriting any previous icon for that
+  category) and the response carries `{ id: "{categoryId}.png", publicUrl,
+  width: 128, height: 128, mimeType: "image/png", storedPath, size,
+  originalFilename }`.
+* Category-icon validation is strict: a missing `file`, an oversized upload,
+  a corrupt/non-image payload, or a buffer that Sharp cannot decode returns
+  `400 Bad Request`. Invalid category-icon payloads use the message
+  `Category icon must be a valid PNG, JPEG, GIF, or WebP image.` and **are
+  not persisted** — the existing icon file (if any) on disk is left untouched.
+  The multipart MIME type, the filename extension, and any browser `accept`
+  metadata are not trusted as proof of validity.
 * A missing `file` part, an oversized upload, a corrupt image, or a decoded logo
   in another format returns `400 Bad Request`. Invalid logo payloads use the
   message `Logo must be a valid PNG, JPEG, GIF, or WebP image.` and are not