better jpeg maximum size estimate

Empirically, based on a series of photos of flowers at a particular resolution, jpeg size grows proportional to `q**-.75` where `q` is the jpeg quality number (smaller is higher quality), and `w*h*(q**.75)/2` is about 10% larger than the flower files at a range of qualities. Different resolutions might have different characteristics, and there's no guarantee that "the most visually complicated scene" won't require a lot more bits than my particular vase of flowers.

We need to know a _safe maximum size_ because if the encoded jpeg data exceeds its buffer, the image can't be captured. But we don't want it to be far too big, or else we use up too much RAM. (target device is esp32-s2 with 2MB PSRAM; if it can't capture the highest pixel size at the best quality, it's okay)

esp32-cam uses `w*h/5` which seems fine (an over estimate) for images at the default quality of q=12. The lowest usable quality number at 2560x1920 seems to be q=5, with failed captures (even with large buffer sizes) becoming more frequent for lower q= numbers, though some q=4 images were captured. Even some of the q=5 images that were "successfully captured" are corrupted, though it's not clear yet whether it's the camera→mcu step or the mcu→sd step where this occurs.

The issue names no files, tests, or entry points. Start by reproducing capture sizes across the stated resolutions and quality values, then determine whether corruption occurs between the camera and MCU or between the MCU and SD card. Done means a validated safe maximum-size estimate that fits the target device's memory constraints.

Written by the indexing model from the issue text.