tidy-event: the merger's gen counter does not span a Flush

[dinstein]

Nightly tidy pass over internal/event (2026-08-10 07:18 round). Records a
behaviour defect; the fix follows on its own branch.

Merger.gen is documented as the answer to "a timer that has begun firing
cannot be stopped". It counts per entry, and a fresh entry starts at zero,
so it answers that question for a settler reset and not for the same race
across Flush:

1. a key's timer begins firing, so its stop() returns false;
2. Flush detaches and emits that entry and clears the map;
3. the same key is Added again — a new entry, at gen 0;
4. the stranded callback matches the new entry by generation and fires it
   immediately instead of a window later.

A coalescer entry is never reset, so its timer always holds gen 0, which is
what makes the collision reachable rather than theoretical. Reproduced
deterministically through the injectable timerFactory before recording.

The consequence is mild and the report says so: one notification arrives up
to a window early, and the bus contract already makes that safe — consumers
re-read authoritative state rather than treating an event as a log. What is
worth recording is that the mechanism which would prevent it is the one
described two lines above in the same document, applied one level too narrowly.
A monotonic sequence on the Merger gives every armed timer a generation
nothing else can hold, and subsumes the settler case.

• Pass C — recorded in docs/modules/config.md beside the gen
  invariant it bends.
• Pass A / Pass B — nothing cleared the bar. bus.go's
  remove-then-close ordering against Publish's read lock is stated and
  correct, and fire already detaches under the lock and builds outside it.

Short lane: docs-only, so go test ./test/buildrules/ is the local
verdict. Green.