[e54-bot]

A 3440x1440 screenshot could not be recognized: every capture was squeezed onto the 16:9 canvas, which distorted all ROIs. The HUD actually keeps its height scale and stays attached to the screen edges.

Ultrawide sources (about 2.39:1, within 3%: 21:9, 2560x1080, 3440x1440, 3840x1600) are now normalized to the standard height with a proportionally wider canvas. Left ROIs stay put, right ROIs follow the right edge, and central ROIs sit in the middle; the side is derived from each ROI's position, so no layout YAML or manifest changes. They are no longer flagged cropped or quality.possible_crop. Other wide ratios still are. debug.roi_coordinates and normalized_size report the canvas actually used.

The Rust crop-batch and inspect use the same canvas, anchoring and quality rules, so Studio crops ultrawide screenshots where recognition reads them. Canvas width uses integer half-up rounding in both languages.

Verification:

• A real 3440x1440 submission screenshot (kept out of the repo) now yields deaths, skips, map, difficulty, version and viewer player through the full service; Rust crop-batch boxes and normalized size match the Python ones exactly on it.
• Regression test with synthetic noise: left and right ROI crops of an ultrawide image are identical to the 16:9 image they were widened from. It fails when the ultrawide branch is disabled.
• Quality tests cover accepted ultrawide sizes and a still-flagged 2:1 image. 314 Python tests and 5 Rust tests pass.

Limits:

• Geometry is confirmed from one real screenshot; the right panel crop sits slightly off its standard position (left edge clipped by about 10px at 720p) without affecting the read values.
• That screenshot still reports run_code null and hero_progress_missing, which comes from the current v6 layout versus the newer HUD, not from the aspect ratio.
• Ratios other than 21:9 (for example 32:9, 4:3) are still treated as possible crops until a real screenshot shows how their HUD is placed.