docs: note the AE-VMAX-clamp follow-up — wire-rate cap isn't VEDU

After this PR landed, follow-up investigation found the 140-fps
wire-rate cap at 480×352 isn't VEDU encoder throughput as we
suspected in §6.2. Tracing /proc/umap/isp showed MaxLine=2060
during a 140-fps run: at HMAX=0x100 and VMAX=2060, sensor fps =
72.8 MHz / (256 × 2060) = 138 — the wire rate IS the sensor rate,
just at much-larger-than-needed VMAX.

The AE library calls cmos_slow_framerate_set every frame with its
chosen VMAX. For M7 mode it picks values ~2.5× the datasheet
vmax_min, leaving 2× speed on the table. Clamping VMAX to
vmax_min in that function more than doubles wire-rate fps:
480×352 @240 went from 140 fps to 319 fps (+128%) on hi3516ev300.

The clamp isn't landed here — it shrinks AE max-integration-time
from ~28ms to ~3ms, which is fine for FPV daylight but unusable
indoors. A follow-up PR adds it behind an opt-in sensor-INI
dispatch (`Isp_SnsMode=5` = M7 + FPS-priority AE), with the
trade-off documented and the gk init failure at 480×352 noted as
a known issue.

§8.5 added to the doc with the head-to-head table and pointer to
the kaeru reference (`v4-ae-vmax-clamp-doubles-deliverable-fps`)
and the companion PR.

Author: Vixand

docs/imx335-v4-high-fps.md

@@ -897,6 +897,35 @@ sustain h265 at usable quality. The high-fps regime is useful
 for *measurement / latency* applications (FPV, machine vision)
 not for storage / streaming.
 
+### 8.5 AE-VMAX clamp — the wire-rate cap is *not* VEDU after all
+
+After PR #100 merged, follow-up investigation found that the 140 fps
+wire-rate cap at 480×352 is *not* a VEDU encoder limit. The AE
+library writes VMAX to ~2060 lines instead of the datasheet
+minimum (840 lines for crop_h=352), dragging real sensor rate to
+half of theoretical. Clamping VMAX to `vmax_min` inside
+`cmos_slow_framerate_set` (the per-frame VMAX-update path that AE
+calls every frame) more than doubles the deliverable rate:
+
+| Crop @ req fps | PR #100 (no clamp) | With AE-VMAX clamp | Lift |
+|---|---|---|---|
+| 1280×720 @100 | 56 fps | **123 fps** | +120% |
+| 800×480 @130  | 83 fps | **225 fps** | +171% |
+| 800×480 @240  | 110 fps | **237 fps** | +115% |
+| 480×352 @240  | 140 fps | **319 fps** | +128% |
+
+The trade-off is exposure: VMAX=840 caps max integration time at
+~2.9 ms (vs ~28 ms otherwise). Fine for FPV daylight, bad for
+indoor IP-cam. Needs a config gate.
+
+The clamp is *not* part of this PR (it changes AE behaviour for
+every M7 user). A follow-up PR adds it behind an opt-in dispatch
+(`Isp_SnsMode=5` in the sensor INI: M7 + FPS-priority AE),
+documenting the exposure trade-off, with the gk init failure at
+480×352 as a known issue to debug separately. See
+`v4-ae-vmax-clamp-doubles-deliverable-fps` in kaeru and the
+companion PR.
+
 ## 9. Critical files and line references
 
 - `libraries/sensor/hi3516ev200/sony_imx335/imx335_sensor_ctl.c:811`