fix: clip pad ±3s + OSD-clock alignment at cut points (single-frame OCR)

docs/deployment.md

@@ -103,6 +103,19 @@ under the hood) and returns the file as an attachment.
 - URL keys (`.env`): `MOTIONEYE_URL` (base URL; empty → 404
   `motionEye belum dikonfigurasi (MOTIONEYE_URL)`), `MOTIONEYE_CAMERA_ID`
   (default `2`).
+- `MOTIONEYE_CLIP_PAD` — float seconds padded before/after the batch window
+  at both cut points (default `3` → ±3 s; empty/invalid falls back to `3.0`).
+- `MOTIONEYE_OSD_ALIGN` — OSD-clock alignment, default **on** (unset = on;
+  `0` / `false` / `no` / empty = off). Why: the camera's burned-in OSD clock
+  and the recording clock drift — up to ~+22 s inside a long clip — because
+  of dropped frames, so filename-based offsets cut at the wrong media time.
+  When on, `clip_batch` OCRs **1 frame** at each cut point (~2–6 s extra per
+  clip, result cached per clip+second) and corrects the cut times. `0` →
+  filename-based offsets only. If OCR fails, it silently falls back to
+  filename-based offsets; both cases log one
+  `[CLIP] batch=... pad=... align=...` line at request start (plus any
+  `[CLIP]` alignment detail lines) — check with `journalctl -u
+  karung-counter-dashboard`.
 - motionEye HTTP API used: `GET /movie/<id>/list/` (recording segments in the
   window) and `GET /movie/<id>/download<path>` (segment bytes).
 - Requires `ffmpeg` / `ffprobe` on PATH — both already installed on the Jetson.