docs(light): correct two javadoc claims the code stopped supporting (#37)

Both were flagged in the wiki as open items. Neither is a wording problem.

FalcoLightingChunk said "Three overrides, and every one of them only reports
something to the scheduler". There are five, and two of them report nothing to
the scheduler: invalidate drops the cached light packet, and onLightUpdated
drops it and sends a fresh one to the viewers. The claim the paragraph exists
to make — that the class holds no computation logic — is true and now rests on
what the class actually contains.

AreaVsPerChunkBenchmark said the chunks are "rebuilt per iteration so neither
side benefits from the light the other one left behind". The second half is
right, and for a different reason than stated: JMH gives each measured method
its own trial, so area() and perChunk() never share chunks. The first half is
wrong — @setup is Level.Trial, so within one trial the chunks are not rebuilt
at all, and since both methods write light into them, every iteration after
the first re-lights already lit chunks.

Whether that moves the number is untested and now says so rather than being
asserted either way. Raising the setup to Level.Iteration would answer it and
would also leave the configuration the published table was measured under, so
it is not something to change while fixing a comment.


Claude-Session: https://claude.ai/code/session_01QzEdy5fN5JKGxJo8gwtNeu

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: TheMeinerLP

falco-benchmarks/src/jmh/java/net/onelitefeather/falco/benchmark/light/AreaVsPerChunkBenchmark.java

@@ -40,9 +40,16 @@
  * of this class: it is a decision, not a report.
  * </p>
  * <p>
- * Both sides run on the same chunks and write into them, which is what the real code does. The
- * chunks are rebuilt per iteration so neither side benefits from the light the other one left
- * behind.
+ * Both sides run on the same chunks and write into them, which is what the real code does. Neither
+ * side benefits from the light the other one left behind, because JMH gives each measured method its
+ * own trial and {@code @Setup(Level.Trial)} builds the chunks afresh for it.
+ * </p>
+ * <p>
+ * Within one trial the chunks are <em>not</em> rebuilt between iterations, and both methods write
+ * light into them, so every iteration after the first measures a re-light of already lit chunks
+ * rather than a first light. Whether that moves the number is untested: raising the setup to
+ * {@link Level#Iteration} would answer it, at the cost of leaving the configuration the published
+ * table was measured under.
  * </p>
  *
  * @author TheMeinerLP

falco-light/src/main/java/net/onelitefeather/falco/light/FalcoLightingChunk.java

@@ -33,10 +33,13 @@
  * {@code InstanceContainer} the server ships with.
  * </p>
  * <p>
- * <b>This class holds no computation logic on purpose.</b> Three overrides, and every one of them
- * only reports something to the scheduler. Everything else — the dirty set, the areas, the executor,
- * the back pressure — lives in {@link ChunkLightScheduler}, so a reader looking for the behaviour
- * finds it in one place rather than spread across a chunk and a scheduler.
+ * <b>This class holds no computation logic on purpose.</b> Five overrides, and none of them computes
+ * light. Three report to the scheduler — {@code setBlock} and {@code onLoad} mark the chunk dirty,
+ * {@code tick} passes the tick on. The other two serve the light packet this chunk sends its
+ * viewers: {@code invalidate} drops the cached packet, and {@code onLightUpdated} drops it and sends
+ * a fresh one. Everything else — the dirty set, the areas, the executor, the back pressure — lives
+ * in {@link ChunkLightScheduler}, so a reader looking for the behaviour finds it in one place rather
+ * than spread across a chunk and a scheduler.
  * </p>
  * <p>
  * <b>What it reports is a position, not just a chunk.</b> {@code setBlock} knows exactly which block