feat(driver): expose per-frame ExposureTime via JNI

[JosephTLockwood]

Why

PhotonVision's libcamera path currently publishes the start-of-exposure timestamp from libcamera::controls::SensorTimestamp as the "image capture time." The scene a detector integrates over actually spans [SOE, SOE+exposure], so the closest single-instant approximation is the midpoint of that window. Surfacing per-frame ExposureTime from libcamera is the prerequisite for the consumer-side mid-exposure correction in PhotonVision/photonvision (PR linked once opened).

What

• Read libcamera::controls::ExposureTime alongside the existing SensorTimestamp in camera_runner.cpp and propagate it through gpu_queue → MatPair.
• New JNI entry Java_org_photonvision_raspi_LibCameraJNI_getFrameExposureTimeUs returns the value in microseconds, matching the existing uS-based exposure setter in this repo.
• value_or(0) from libcamera + MatPair zero-init means callers get 0 when the metadata wasn't populated for the frame, which the consumer treats as "unknown" and leaves the timestamp uncorrected.

Verification

• ./gradlew compileJava and ./gradlew publishToMavenLocal succeed locally.
• The cmake build (and the actual Pi-side validation) is exercised by the existing arm-runner CI job.
• Consumer PR builds green against the locally-published patched jar.

Scope notes

• Single-purpose change. No refactors of unrelated code in the runner.
• USB / V4L path is intentionally untouched: that path has separate caveats around proprietary exposure scales (some Arducam V4L drivers) and unreliable per-frame metadata under auto-exposure. Out of scope here.

[JosephTLockwood]

Paired PhotonVision consumer PR: PhotonVision/photonvision#2489

[mcm001]

Suggested change

	// 0 means libcamera did not populate ExposureTime metadata for this
	// frame. Consumers should treat 0 as "unknown" and not attempt the
	// SOE -> mid-exposure timestamp correction.

MatPair::exposureTimeUs already includes this comment