docs: lens shading resolved from the factory rootfs

The factory image carries a register loader that nothing calls, the app
references an apply script the rootfs does not have, and the OV5648
driver has no regs attribute. No shipped machine applies a per-unit
shading table. BRINGUP item 6 drops the claim; CAMPAIGN-LOG has the
search.

docs/BRINGUP.md

@@ -1156,16 +1156,14 @@ Open items only. Anything closed is in `CAMPAIGN-LOG.md`.
    720 Mbps/lane and what exposure/gain the sensor wants; the details, the
    reachable-mode reasoning and the factory fallback configuration are in
    the headers of kernel patches 0011-0013 (`meta-glowforge-bsp`,
-   `recipes-kernel/linux/`). Also unapplied: the factory's **per-unit lens-shading
+   `recipes-kernel/linux/`). Lens shading (OmniVision LENC) is not a gap: the factory
-   calibration**, an OmniVision LENC register file the factory pushes into the
+   rootfs carries `load_cam_regs.sh`, a loader that writes a register file
-   sensor at every stream start (`load_cam_regs.sh` → a `regs` sysfs attribute
+   into the OV8856 driver's `regs` sysfs attribute (OV8858 `0x58xx`
-   its driver adds; OV8858 `0x58xx` addresses remapped to the OV8856's
+   addresses remapped to `0x59xx`), but nothing calls it; the app
-   `0x59xx`). The files are per-machine data: not in the factory rootfs, and
+   references `/usr/bin/apply_cam_regs.sh`, which is not on the rootfs; the
-   not under `/data` on the bench machine (the partition is shared between the
+   OV5648 driver has no `regs` attribute; and this machine's `/data` holds
-   slots and holds no camera register file). Whether the factory app fetches
+   no register file. No shipped machine applies a per-unit shading table,
-   them from the service at run time is the open question, so a factory-slot
+   so ForgeFIRM owes none. Finally the deferred emulator
-   session with the app running comes before deciding whether to reimplement
-   the mechanism. Finally the deferred emulator
    homing-image smoke, now that the emulator can be pointed at live snapshots.
 7. **Cloud mode.** A print is no longer capped by the ring: the client holds
    the compressed body, fills the ring before the button, and tops it up as it

docs/CAMPAIGN-LOG.md

@@ -4701,6 +4701,31 @@ Nothing left on the board: the drill script was staged in `/tmp` and
 removed, `/data` holds factory state and ForgeFIRM's own files. Owed on
 this image: the full campaign (platform change).
 
+## 2026-08-31: lens shading, resolved from the factory rootfs
+
+Item 6 carried a per-unit lens-shading (OmniVision LENC) table the
+factory was said to push into the sensor at every stream start. The
+factory v2.6.0-2228 rootfs, dumped and searched, says otherwise:
+
+- `/usr/bin/load_cam_regs.sh` exists: it takes `<lid|head> <regfile>`,
+  writes each register line into `/sys/bus/i2c/devices/<bus>-0036/regs`,
+  and remaps OV8858 `0x58xx` addresses to the OV8856's `0x59xx`. Nothing
+  on the rootfs calls it (no script, no init file, no reference in the
+  app binary).
+- The app binary references `/usr/bin/apply_cam_regs.sh` next to its
+  camera-selection strings. That script is not on the rootfs.
+- Only `ov8856.ko` carries the `regs` attribute (`ov8856_regs_attr_store`)
+  and an OTP mode; `ov5648.ko` has neither.
+- On the bench machine (OV5648) `/data` holds no register file, and
+  `/data/manufacturing` did not exist before the 2026-08-20 bench tool
+  created it.
+
+So no shipped machine applies a per-unit shading table: the loader is a
+manufacturing-side tool, the app's hook points at a script the image
+does not carry, and the 5 MP driver has no way to take one. BRINGUP
+item 6 now says so, and the factory-slot session it asked for is not
+needed.
+
 ## Superseded status notes
 
 ### Shared machine services — remaining polish, as listed 2026-08-13