fix(libcamera): publish mid-exposure timestamp

[JosephTLockwood]

Why

PhotonVision's libcamera path currently publishes the start-of-exposure timestamp from libcamera::controls::SensorTimestamp directly. The scene a detector integrates over spans [SOE, SOE+exposure], so the closest single-instant approximation is the midpoint of that window. The existing e2e-latency design doc already acknowledges this residual ("sensor will remain collecting light for up to the total integration time").

Magnitude at typical FRC exposures (~5–15 ms): a 2.5–7.5 ms earlier-bias is removed, which is ~12–37 mm of pose error at 5 m/s drive speed.

What

• LibcameraGpuFrameProvider: read getFrameExposureTimeUs and add exposure/2 (ns) to the published timestamp.
• When the driver returns 0 (libcamera did not populate ExposureTime for the frame), the correction is skipped and behaviour matches today.
• e2e-latency.md: documents the new behaviour and the rolling-shutter caveat.

Dependency

Requires PhotonVision/photon-libcamera-gl-driver#33 (the paired JNI surface). That PR must merge and a driver release that bumps libcameraDriverVersion in build.gradle must land before this PR compiles against the upstream Maven artifact. Local smoke build was verified with ./gradlew publishToMavenLocal on the driver branch.

Scope notes

• libcamera path only. The V4L/USB path has separate caveats around proprietary exposure scales (some Arducam V4L drivers) and unreliable per-frame metadata under auto-exposure, and is explicitly out of scope.
• No feature flag — the driver-returns-0 fallback already covers the unsupported-sensor case, so a config toggle would be redundant.
• Residual row-dependent bias on rolling-shutter sensors is not corrected here.