Re-pose an existing sprite into a new target pose while preserving the character, taking a source image (URL or base64), a pose name (or "Other" with a free-text description), and an optional n (1-4) for how many variations to produce. Only works with sprite image types (not icons, screenshots, etc.). Synchronous until September 10, 2026: the call blocks and returns an array of pose results, each containing the generated image url, the pose and description used, and a suggested motion_prompt tuned for that pose. Credits are charged only on success, scaled by the number of images generated. This is typically the first step before animating: call generatePose to set the character's pose, then feed the result (and its suggested motion_prompt) into animateSprite for the best animation quality; use rotateSprite instead when you want to change the camera angle rather than the pose. Pass an optional request_id to tag the results so you can locate them later via `GET /assets/sprites/results`. Requires an API key (user scope). Async is the intended integration pattern: pass `async: true` and the call returns 202 with a job id - poll `GET /assets/jobs/{id}` (`getApiJob` in MCP), honouring poll_after_ms or long-polling with wait=30, until status is succeeded, whose result field is exactly the response documented for this operation. Synchronous responses are deprecated: they remain the default until September 10, 2026, after which requests default to async and return 202 with a job id; set `async: false` explicitly to keep synchronous behavior during and after the transition. Synchronous calls run on the same queue: the response carries an X-Ludo-Job-Id header, and a job still running after 15 minutes comes back as 202 with the job instead of an error. Each account may have up to 50 generations queued or running at once via the API; a request beyond that returns 429 (code PENDING_JOBS_LIMIT).