Chromatic Calibration: automatic photometric lens fusion with Studio parity

## Goal

Add **Chromatic Calibration with Studio parity** after issue #184 delivers the initial
shared ONE X2/X4 Air camera stitcher. In Studio project terminology this is
`image_fusion`: photometric matching of the two lenses' color and brightness,
not optical chromatic-aberration correction or per-channel lens displacement.
It must be automatic and require no calibration control or setup.

## Evidence already available

- `docs/research/linux-landscape.md` section 6 records the maker SDK's
`EnableStitchFusion` description: it corrects exposure/brightness mismatch
across the seam.
- The exact Studio 6.0.2 Flow On and Flow Off projects authenticated by
`docs/research/studio-video-oracle-602.json` both encode Image Fusion **ON**.
They isolate optical flow, not Image Fusion, and provide no Image-Fusion-off
result or coefficients.
- `crates/render/src/chromatic.rs` and `crates/render/src/chroma.rs` retain a
GPU correction field whose zero value is exact neutral; the generic
compositor applies per-lens additive Y/Cb/Cr corrections before RGB
conversion and blending. The selected direct Type-2 path does not currently
consume that correction.
- Issue #103 is related historical seam-photometry work, not this completion
item. Its applied field was owner-rejected; its measurement and
anti-acceptance record in `docs/research/seam-blending.md` remains binding.

## Required work

1. Preserve an exact default-neutral per-lens photometric input at the shared
GPU source-sampling/fusion boundary. Apply it to each geometrically selected
lens sample before alpha blending. Missing or not-yet-measured data must
produce byte-identical neutral output.
2. Derive observations only from source locations proven to represent the same
scene point by the active per-frame geometry. Gate or reject occlusion,
parallax, invalid coverage and unaligned seam samples. Do not infer color
from same-direction samples before alignment.
3. Estimate automatically from pixels. Do not use per-clip tuning, a setup
ritual, shutter as a brightness ratio, invented coefficients, or an
unsupported claim that Studio's field/grid applies unchanged.
4. Keep the implementation GPU-resident and frame/capture identity explicit.
Reuse qualified existing machinery only where its coordinate, lens-order
and temporal contracts match the shared engine.

## Acceptance

- Prove neutral mode exactly preserves the issue #184 render for both cameras.
- Compare actual rendered sequences with the relevant Studio setting isolated;
inspect the correction's full painted area and seam trace, then obtain the
owner's eye verdict. Metrics alone do not establish parity.
- Report active-playback throughput at output resolution plus median, p95, p99
and maximum frame times, source cadence and audio underruns. A kernel-only
result is insufficient.

This issue is required follow-on work. It is not implemented, verified or
Studio-parity-complete today. Broader optimization RE remains frozen. Reuse
existing references first; new evidence should answer a bounded photometric
question, not reopen general stitching research.

Start at crates/render/src/chromatic.rs and crates/render/src/chroma.rs, focusing on the GPU sampling/fusion path where the direct Type-2 branch currently ignores the per-lens correction field. Read docs/research/linux-landscape.md, docs/research/studio-video-oracle-602.json, and docs/research/seam-blending.md first to align with documented behavior and constraints. Trace sample-selection and geometric alignment in that path to apply automatic photometric fusion only to valid same-scene seams. Done means neutral mode is byte-identical to issue #184 output, studio ON/OFF image-fusion comparisons are reviewed, and throughput plus frame-time/underrun metrics are reported.

由索引模型根據 Issue 內容生成。