docs: state which limits an aggregate accepts

The upgrade note described the accepted shapes loosely: it did not
separate a direction-less limit on a `SELECT DISTINCT` aggregate from a
top-k limit, and it listed none of the conditions a top-k limit also has
to meet. List the three shapes that build, and what each one requires.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01D7arPq4Frxu8byr17mqVKA

Author: claude

docs/source/library-user-guide/upgrading/56.0.0.md

@@ -438,11 +438,28 @@ optimizer rules work, not a public API. The builder, `AggregateExec::builder`,
 - Anyone building an `AggregateExec` with a limit that the aggregate cannot
   execute, or decoding such a plan from protobuf: this is now an error at plan
   time instead of an internal error, a panic, or silently ignored `FILTER`
-  expressions at execution time. A limit is only executable on an aggregate
-  with no aggregate expressions (a `SELECT DISTINCT`-style aggregate), where the
-  groups themselves are the result, or on one with a single `MIN`/`MAX`
-  expression and a single group by expression, where the limit either carries no
-  ordering direction or carries the one that aggregate already implies.
+  expressions at execution time.
+
+A limit is accepted on three shapes of aggregate:
+
+- An aggregate with no group by expressions. It produces a single row, so the
+  limit is ignored.
+- A `SELECT DISTINCT`-style aggregate: a group by, no aggregate expressions, no
+  `FILTER`, and no ordering direction on the limit. The groups themselves are
+  the result, so the stream stops once it holds enough of them.
+- A top-k aggregate, which needs an ordering direction and takes it from a
+  single `MIN`/`MAX` aggregate expression, from the limit, or from both. When it
+  comes from both they have to agree: the top-k stream uses the direction of the
+  aggregate and ignores the one on the limit, so a limit that disagrees keeps
+  the wrong K groups. A top-k aggregate must also have a limit above `0`,
+  exactly one group by expression and no grouping sets, no `FILTER` on any
+  aggregate expression, and a group key and value type the top-k queue
+  supports.
+
+Every other shape is rejected. A limit on an aggregate that has to accumulate,
+such as `COUNT`, is the important one: the grouped streams honor a limit by no
+longer reading input once they hold enough groups, which returns partial
+aggregate values for the groups they kept.
 
 **Migration guide:**