fix(scanner): meter exposure on the centre of the frame

[bmc08gt]

Scanning fails outright when a bright screen washes the code out. The cause is that auto-exposure is effectively part of the detector, and Android never configured it.

The detector has no exposure tolerance

Candidate finding in scanner.cpp runs entirely on one binary image:

threshold(greyscale, whitish, 170, 255, THRESH_BINARY);

Every contour, every ellipse, and therefore every code the scanner ever finds comes out of that. The cutoff is an absolute luminance, not a local or adaptive one. So the detector never asks whether the code has contrast — it asks whether the code's light ink lands above 170 and its dark ink below it.

Measured on a Solana Seeker (WashoutToleranceTest):

sweep	decodes	fails
overexposure (ceiling clipped, floor rising)	black level up to 170	180
underexposure (floor at black, ceiling falling)	white level down to 175	165
contrast closing on a mid-grey	span 86 (85 ↔ 171)	span 76 (90 ↔ 166)

The third row is the one that matters. A code rendered at 90 ↔ 166 is plainly legible and completely invisible to the scanner — not because contrast ran out, but because the band stopped straddling 170. This is an exposure bug, not a contrast one.

A clipped code is therefore not a degraded input. It is a uniform white slab with no contours to find, and nothing downstream can recover it.

Android never asked for exposure metering

Metering was left to the camera's whole-frame default, and AE was never requested — not at bind, and not on tap, where the existing action carried FLAG_AF alone. Pointed at a code on a phone screen in a dim room, whole-frame metering exposes for the room and drives the screen into clipping.

iOS has pinned exposurePointOfInterest to the centre since CameraSession was written:

if device.isExposureModeSupported(.continuousAutoExposure) {
    device.exposureMode = .continuousAutoExposure
}
if device.isExposurePointOfInterestSupported {
    device.exposurePointOfInterest = CGPoint(x: 0.5, y: 0.5)
}

This closes that parity gap rather than inventing a new behaviour. The two scanner.cpp copies are otherwise identical here — the divergence was entirely in the camera configuration.

The fix

Request AE on the centre of the frame and keep it there, and add FLAG_AE to tap-to-focus so a tap fixes exposure too. Since auto-cancel drops all 3A regions rather than only the ones the tap set, the tap re-arms the baseline afterwards instead of silently costing it.

Two details are load-bearing and don't read as such:

• AE only, no AF. Adding FLAG_AF to a request with auto-cancel disabled would fire a one-shot autofocus and leave focus locked wherever it landed — the opposite of what a scanner wants. Focus stays in the camera's continuous mode.
• Applied when the stream is running, not when bind returns. startFocusAndMetering is refused with OperationCanceledException: Camera is not active until the camera has opened, and it refuses silently. The first cut of this fix asked at bind time and was cancelled every time, while looking from the source exactly like a working fix. The device test caught it.

Not done here

The 170 constant is the deeper problem — an adaptive or Otsu threshold would make the detector exposure-agnostic. But scanner.cpp is maintained in parallel on iOS, and changing the threshold trades against false positives in a way synthetic frames cannot measure. That's a cross-platform decision, not a drive-by.

Was stacked on #1310, which has since landed; rebased onto code/cash and this is now standalone.