laser_stream_test: rule 19 names every laser session that runs with the dose curve in force

Rule 19 of the header said that every session but the rolloff reference
run has laser_dose_curve = off. Beside that run, four laser sessions run
with the curve in force: rolloff-g1 and rolloff-g2 (rule 20) and
rolloff-two (rule 23) under DENSITY_CONF_CURVED, which carries no curve
key, and jog-dark (rule 22), which runs with no configuration at all,
so the controller's curve_default applies. Rule 20 itself says "under
M4 with the curve in force". Rule 19 now says that every laser session
but the rolloff ones (rules 20 and 23) and the jog run (rule 22) runs
with laser_dose_curve = off. The z session carries no laser key and
fires nothing, so "laser session" leaves it out.

Proof: header text only, no behavior change. python3 -B -m py_compile
and pyflakes are clean on scripts/bench/laser_stream_test.py, and the
harness passes whole, every session, against the native null-sink
build of the driver at badc832 (-DGFMCODE_WAIT_S=5.0). The harness runs
in grblHAL-glowforge CI (the step "Laser stream emission rules",
python3 forgefirm/scripts/bench/laser_stream_test.py
build/grblHAL_glowforge).

Acceptance: none; the header docstring of a harness outside every
covers map.

scripts/bench/laser_stream_test.py

@@ -84,7 +84,8 @@ over TCP, then checks the dumps against the kernel feeder contract:
  19. the dose curve's mapping of S onto delivered light is
      laser_arm_test.c case P's, and the rolloff reference run (rule 23)
      pins one point of it end to end: the S300 cruise renders the density
-     the curve maps 30 % light onto; every other session runs with
+     the curve maps 30 % light onto; every laser session but the rolloff
+     ones (rules 20 and 23) and the jog run (rule 22) runs with
      laser_dose_curve = off so its S-to-level arithmetic stays exact
  20. the corner rolloff starves the slow spots: under M4 with the curve
      in force, the accelerate-in head of a line renders less density at