fix(list): arrange today and someday the way the app does

[ryanlewis]

Closes #237

Before and after, by uuid against the app

This changes numbered rows in two views, so here is the position-match count each way:

view	before	after
today --include-completed	4 / 27	27 / 27
someday	0 / 6	6 / 6
anytime (unchanged, as a control)	105 / 105	105 / 105

things today with no flag is that same order with the closed rows removed, 18 of 18.

What changed

The app arranges Today, Anytime and Someday identically: unfiled items first, then areas in area order, and inside an area its own loose to-dos before those of its projects. #236 gave anytime those keys; this gives them to the other two from the same constant, renamed from anytimeGrouping to listGrouping now that three views take it.

today needed more than the missing grouping key

The issue said to keep today's existing within-day key and add only what is missing. Adding only the loose-before-project key took today from 4 of 27 to 9 of 27, so I measured the app's own Today to find the rest. Two of today's within-day keys turned out to be wrong:

• t.status ASC put the closed items --include-completed keeps at the end of their group. The app leaves a closed item where it was, struck through — six closed rows were interleaved through three groups in the measured list.
• t.todayIndexReferenceDate DESC reordered whole groups by the day a todayIndex was last rewritten. That column stamps which day a todayIndex belongs to; the app does not sort on it.

With both removed and todayIndex alone as the within-group key, today reproduces the app in every position. I confirmed the proposed keys directly against the app's list before touching the code, so the removal is measured rather than inferred.

Flagging it because it is more than the issue asked for. The alternative was leaving today at 9 of 27, which would not close the issue.

Tests

Three added: today grouping loose to-dos before project to-dos across two areas; today keeping a closed row in place among open ones under --include-completed; and someday leading with unfiled items then areas in area order. Each seeds indexes running against the expected order so the key under test is the one doing the work. No existing test covered the two removed keys.

Unverified, recorded in the comment

A Someday project row and a loose Someday to-do in the same area both fall through to t."index", comparing a project's index with a to-do's — different spaces, the same concern the repeating view's ordering calls out. It is no worse than the bare index ordering it replaces, and there is no Someday project in the data to measure the app's answer against.

Docs

docs/content/commands.md now describes the arrangement once for the three views that share it, notes that today orders within a group by the position Things keeps for the day, and says that someday reaches only the unfiled-then-areas half, since its filter excludes every to-do with a parent project.

make test and make lint are clean.