fix(list): include cancelled items in logbook

[ryanlewis]

Closes #210

What changed

logbook now returns cancelled items alongside completed ones. The Logbook is where Things files everything closed, not just everything finished: cancelling a to-do or a project logs it under its stop date beside the completed rows, and the app shows both. The view filtered t.status = 3 alone, so cancelled rows never appeared.

The filter is now t.status IN (2, 3). Nothing else about the view moved: it keeps ORDER BY t.stopDate DESC, so cancelled rows interleave with completed ones by date rather than forming a block, and it keeps the literal reading of the database it shares with trash.

Callers tell the two apart by status, which needed no output change. JSON already carries "completed" or "cancelled", and plain output already prints [x] and [~].

Verified against the real database

Read the live database with sqlite3 -readonly, compared against the app's own Logbook membership via AppleScript (id of to dos of list "Logbook"), by uuid.

	count
App's Logbook	910
CLI list logbook before	1190
CLI list logbook after	1334
Rows the app shows that the CLI was missing, before	39
Rows the app shows that the CLI is missing, now	0

The CLI now returns every row the app's Logbook shows. The 39 recovered are 33 cancelled to-dos and 6 cancelled projects, and all 6 projects are in the app's list. Both uuids named in the issue, 3p5oMeS6jVjUTNCRhuPEuW and PtV3Uvf1rRB7326cFPYvEN, are among them. Stop-date ordering stays monotonically non-increasing across the widened set, with cancelled rows interleaved rather than blocked.

--include-completed is unaffected: it is rejected on any view but today, logbook included, and still is.

What this does not fix

The CLI returns 1334 rows where the app shows 910, and the 424-row difference is not what this issue is about. I measured where it comes from, because it would otherwise look like this PR made the gap worse:

• 341 rows are the children of a closed or trashed project. The app shows the closed project as one row and folds its contents into it; the CLI lists each child separately. 292 of those are completed and were already returned before this PR; 49 are cancelled and arrive with it.
• 6 rows were closed today. The app keeps them under Today until manualLogDate advances, which is the same rule --include-completed already implements for the today view.
• The rest are the children of trashed projects and template rows, which trash and logbook report deliberately under the decisions in bug: someday, anytime, upcoming, inbox and deadlines views lack the trashed-project guard #155 and fix(list): include projects in someday and logbook #209.

None of these are cancelled-specific and all predate this change in kind. They are worth their own issues.

Tests

Five tests in internal/db/tasks_test.go over a new seedLogbookCancelled helper, whose stop dates interleave the two statuses while "index" runs against that order, so a view that grouped by status or fell back to "index" would fail:

• cancelled to-dos and cancelled projects are listed, and status and type identify each
• cancelled rows sort by stop date among the completed ones
• open rows, a trashed cancelled row and a cancelled heading stay out
• --area finds a cancelled row through its area; --project cannot match a project row
• cancelled rows do not leak into today, upcoming, anytime, someday or the catch-all view, each seeded with a cancelled row shaped to land in that view but for its status, so only the t.status = 0 clause keeps it out. Mutation-checked: dropping that clause from someday or upcoming fails the test.

TestListTasksViews expected logbook to hold only t-done, while its own fixture comment already labelled t-cancelled as a logbook row. That expectation now matches the comment.

Docs

internal/skill/SKILL.md, docs/content/commands.md, docs/content/agents.md and README.md: the Logbook is described as everything closed rather than everything completed, with status named as the way to separate the two and a jq filter for agents that mean finished rather than closed.

The review also caught that every jq 'select(...)' example in the agent-facing docs was broken, including ones this PR did not add. -j emits a JSON array, so jq 'select(.status=="completed")' aborts with Cannot index array with string. All of them now read jq '.[] | select(...)', which I checked by running both forms. Those examples ship in-binary for agents to copy literally, so leaving the pre-existing ones wrong while fixing the new one would have been worse than fixing the set.