Release 2.3.1

What's New

A single-fix release: a terminal sink is no longer asked to invent an entity to
dispatch to.

Bug Fixes

• handler-streamlet-foreign-message no longer fires on a sink that does real
  work. The rule asked a sink whose handler contains no tell why it handles
  messages without dispatching to an entity. That is a fair question of an
  intake sink — one placed to receive from outside and hand the work to an
  entity — and the wrong question of a terminal one, which is a boundary into
  something that is not an entity at all. The rule had already been narrowed
  twice for exactly that reason, once for the routing shapes (split, merge,
  flow) and once for repository and projector, each time by exempting one
  more processor kind.

  A display screen was the third such boundary: a kitchen display that logs a
  ticket and renders it has no entity to tell, and telling the ticket back to
  the entity that yielded it is a round trip no generator should emit.

  Rather than exempt a fourth kind, the rule now asks the question it can answer
  honestly: has the sink said what it does with what it receives? A clause
  containing executable work — a tell, a log, a put to an output, a write,
  a refusal, a code block — has said, whatever the destination. A clause holding
  only prose (do "…") or nothing has not, and that is the only case still
  reported.

  Why this generalizes: "a sink dispatches into entities" was never a fact about
  sinks, it was a fact about one use of them, so every new kind of boundary —
  storage, a projection, a screen — arrived as a false positive in a model that
  was already correct.

Changed diagnostics

• The message for handler-streamlet-foreign-message now reads "handles
  messages but does not say what it does with them", with a suggestion naming
  every way a sink can say so. The previous wording named tell and entities
  specifically, which the narrowed rule no longer asks about — a true diagnostic
  with a false explanation.

  The rule id is unchanged. Tooling that keys on RuleId values is
  unaffected; anything matching on the message text of this one rule needs
  updating. The rule's severity (Completeness) and gating
  (--show-completeness-warnings) are also unchanged.

Internal

• The enumeration of "executable work" now exists once
  (ValidationPass.isExecutableStatement) rather than in both the sink check
  and classifyHandlers, so the two cannot drift apart as statement kinds are
  added. It is an exhaustive match with no wildcard, so a new statement kind
  fails the build rather than silently counting as neither work nor prose.
• TerminalSinkDoesWorkTest pins all four cases, including the prose-only
  negative control that must still report.