fix(bruno): convert drifted body keys to body.data — CLI scenario runs now carry bodies

Follow-up to the sweep route audit, correcting its diagnosis: the CLI
DOES read .yml bodies — via OpenCollection's `body.data` string form
(the NewDevDBSetup script always worked because it used it). The
failing scenario POSTs used `body.json` (structured) / `body.jsonBody`
(string) — keys the CLI silently ignores, sending Content-Length: 0
with form-urlencoded content-type, so every server bind failed.

- 81 bodies converted to data-form (json maps serialized; jsonBody
  strings kept verbatim, {{vars}} intact).
- 6 pre-existing TRUNCATED payloads repaired: the original generator
  cut bodies at the first {{var}} (every SHA-256-identified scenario
  plus Sync Progress/Sync Bookmarks shipped mid-JSON and 400'd from
  day one). Rewritten whole, faithful to each file's documented
  purpose; book_sha256/book_uuid added to the environment.
- environments: opds_base_url correction from the sweep retained.

Verified live against the rebuilt dev container: the full koreader
scenario tree runs green through `bru run` — 14/14 (202s across
immediate/checkpoint/SHA-256 progress, 200s bookmarks, highlights,
notes; SHA-256 book identification exercised against a real
file_sha256).

bruno/conflicts/scenarios/Bulk Resolve Highest Progress.yml

@@ -8,39 +8,11 @@ http:
   auth: inherit
   body:
     type: json
-    jsonBody: "{\n    \"conflict_ids\": [\n      \"{{conflictId1"
+    data: "{\n    \"conflict_ids\": [\n      \"{{conflictId1"
   headers:
   - key: Content-Type
     value: application/json
   - key: Authorization
     value: Bearer {{authToken
-
-docs: |-
-  ## Bulk Resolve with Highest Progress Strategy
-  
-    Resolves multiple sync conflicts using the "highest_progress" strategy, which keeps the reading progress with the highest percentage read.
-  
-    **Method:** POST
-  
-    **Endpoint:** /api/conflicts/bulk-resolve
-  
-    **Authentication:** Bearer token
-  
-    **Request Body:**
-    - `conflict_ids` (array): Array of conflict UUIDs to resolve
-    - `strategy` (string): Must be "highest_progress"
-  
-    **Response:**
-    - `results` (array): Results for each conflict resolution
-    - `total` (number): Total number of conflicts processed
-    - `success` (number): Number of successfully resolved conflicts
-    - `failed` (number): Number of failed resolutions
-  
-    **Status Codes:**
-    - 200: Success
-    - 400: Invalid request data
-    - 401: Unauthorized
-    - 403: Forbidden
-    - 500: Internal server error
-  
-    **Note:** The highest progress strategy is ideal when you want to preserve the most reading progress across devices. Use this when you've been reading on multiple devices and want to keep the furthest position.
+docs: "## Bulk Resolve with Highest Progress Strategy\n\n  Resolves multiple sync conflicts using the \"highest_progress\" strategy, which keeps the reading progress with the highest percentage read.\n\n  **Method:** POST\n\n  **Endpoint:** /api/conflicts/bulk-resolve\n\n  **Authentication:** Bearer token\n\n  **Request Body:**\n  - `conflict_ids` (array): Array of conflict UUIDs to resolve\n  - `strategy` (string): Must be \"highest_progress\"\n\n  **Response:**\n  - `results` (array): Results for each conflict resolution\n  - `total` (number): Total number of conflicts processed\n  - `success` (number): Number of successfully resolved conflicts\n  - `failed` (number): Number of failed resolutions\n\n  **Status Codes:**\n  - 200: Success\n  - 400: Invalid request data\n  - 401: Unauthorized\n  - 403: Forbidden\n  - 500: Internal server error\n\n  **Note:** The highest progress strategy is ideal when you want to preserve the most reading progress across devices. Use this when you've been\
+  \ reading on multiple devices and want to keep the furthest position."