phase 3: parallel-startup timing trace anchored to camera-event arrival

Adds per-stage timing logs to both the stream and snapshot paths,
all relative to a single t=0 anchor: the moment the camera event
arrived in handleCameraEvent. Lets us see whether snapshot and
stream actually start in parallel (they should, within ~2ms) and
where wall-clock goes inside each path.

handleCameraEvent now captures tEvent = Date.now() and threads it
into startStream(v, tEvent). startStream threads it further into
pushSnapshot(v, cam, tEvent). Both helpers define a `since()` arrow
that computes the current offset.

New log lines on wake:

  event MotionSensor -> "kitchen": fired at +0ms (wake)
  stream "kitchen": start +0ms
  stream "kitchen": socket connect requested +1ms
  snapshot "kitchen": start +1ms
  snapshot "kitchen": takePicture +320ms
  stream "kitchen": socket connect open +24ms
  snapshot "kitchen": transform +458ms via sharp (217KB)
  snapshot "kitchen": post sent +459ms
  snapshot "kitchen": post acked +551ms ← first user-visible paint
  stream "kitchen": first ffmpeg frame +780ms (jpeg=210KB)
  stream "kitchen": first socket.write +781ms

post_acked is the snapshot's true glass-to-glass: /frame returns
after display_flip_back_buffer, so by the time the response
resolves the firmware has the new pixels queued for the next DPI
scanout. No separate firmware-side wiring needed for the snapshot
path's g2g measurement.

The stream path's true g2g still needs the 16-byte header
extension in Phase 4 — `first socket.write` is just "Scrypted sent
the bytes," not "panel showed them."

0 files changed, 0 insertions, 0 deletions