One group's share of the whole matching corpus, when a query asked for counts with group_by.
Keyed by `(workspace, key)`, because a ListId belongs to one workspace's list table and folding two workspaces' rails together would name a group neither of them has. A bucket key is universal rather than workspace-scoped, and the rows stay per workspace anyway: a task belongs to exactly one workspace, so a cross-workspace rail sums them and loses nothing, while folding here would throw away an answer a client may want.
Under group_by: "list" these do not overlap: koru.list is cardinality-one, so a task is in exactly one list or in none, and the counts sum to at most the number of matching tasks. A list nothing matches has no row rather than a zero - a client draws its rail from the list table and reads a missing group as an empty bucket. Buckets partition the corpus for the same reason and completely: every task is in exactly one of the five, so those counts sum to the whole matching set.
