CritterCrush: switch DetectMutualMatch back to the nullable event return once wolverine#4312 ships

[jeremydmiller]

CritterCrush/CritterCrush/Discovery/DetectMutualMatch.cs currently returns EventsToAppend with return []; for the nothing-to-do branches — a workaround for JasperFx/wolverine#4309, where a nullable single-event return from an aggregate-workflow handler reached EventStream.AppendOne(null) and threw. The fix is JasperFx/wolverine#4312 (null event returns become a no-op, matching cascaded-message semantics).

Once #4312 merges and the sample's Wolverine reference moves to a version carrying it:

1. Restore the nullable form — it reads better for a single-possible-event automation:

   public static MutualMatchDetected? Handle(DogLiked liked, [WriteModel] SwipePair pair)
   {
       if (pair.Matched) return null;
       if (pair.LikedBy.Count < 2) return null;
       return new MutualMatchDetected(pair.Id, pair.LikedBy[0], pair.LikedBy[1]);
   }

2. Re-run the spec suite (the "A mutual like produces a match" and no-op scenarios cover both branches).
3. Update the matching guidance: the critterstack-sdd-code-from-specs automation reference (JasperFx/ai-skills#172, references/automation-slice.md) carries a warning telling agents to prefer EventsToAppend "until #4309 lands" — soften it to present the nullable form as legal from that Wolverine version, keeping EventsToAppend for the multi-event case.

From the CritterCrush review session, 2026-09-06.