perf(scanner): drop two full-frame adaptive thresholds that nothing reads

[bmc08gt]

detectKikCode opened with a pair of full-frame 21×21 Gaussian adaptive thresholds:

// --- START OF EDIT ---
adaptiveThreshold(greyscale, blackish, 255, ADAPTIVE_THRESH_GAUSSIAN_C, THRESH_BINARY_INV, 21, 5);
adaptiveThreshold(greyscale, whitish,  255, ADAPTIVE_THRESH_GAUSSIAN_C, THRESH_BINARY,     21, 5);
// --- END OF EDIT ---

Neither result is ever read.

• whitish is unconditionally overwritten before anything touches it, by the global threshold(greyscale, whitish, 170, 255, THRESH_BINARY) a few dozen lines down.
• blackish is only read on the inverted-code path (!check_high), and that path recomputes it itself, lazily, behind blackish_created — with a different algorithm (ADAPTIVE_THRESH_MEAN_C, at the quality-dependent width rather than a hardcoded 21).

So every analyzed frame paid for two full-frame adaptive thresholds whose output was discarded.

Cost, measured

S25 Ultra, 30 iterations per case, native detect only (no plane conversion), through the real render path:

frame	code present	before	after
1280×720	yes	10.44 ms	4.99 ms
1280×720	no	14.30 ms	8.90 ms
1920×1080	yes	8.27 ms	2.79 ms
1920×1080	no	10.01 ms	4.47 ms

~5.5 ms off every frame, hit or miss — the "no code" rows are the ones that matter most, since that is what the analyzer pays while the user is still lining the phone up. This is larger than the luminance-plane fast path it stacks on top of.

The instrumented sweep still decodes 18/18 and stride parity is unchanged, which is what deleting values nothing consumes should look like.

iOS never carried this block.

Stacked on #1306.