Order project list by sortOrder, as Linear's app does

[schpetbot]

#290 (merged, unreleased) ordered project list by status-type flow rank, then status.position, then sortOrder. That rule was reconstructed from schema docs and never checked against the Linear app. It is wrong.

Evidence

The workspace has ten projects, five of them probes created for this check, one per status. Linear's projects list shows them in exactly this order:

Project	Status	sortOrder
E probe backlog	backlog	-9086
D probe planned	planned	-8018
C probe in progress	started	-7086
B probe completed	completed	-6020
A probe canceled	canceled	-4964
Triage 221-225 2026-05-22	backlog	-3971
QA Test Project	backlog	-2949
PR Test Project with Initiative	backlog	-2032
PR Test Project	backlog	-1019
Linear CLI One point oh	backlog	20.21

That is sortOrder ascending, with status ignored. If the app grouped by status, "E probe backlog" would sit with the other backlog projects instead of ahead of D. On main the CLI prints E, Triage, QA, PR…, PR…, Linear CLI, D, C, B, A. With this change, project list against the live workspace prints the table's order exactly.

What changed

• compareProjectsForDisplay orders by sortOrder ascending, then name, then id. The status-type ranking and the status.position key are gone. The non-finite check on sortOrder stays, so a null key errors instead of scrambling the list.
• ProjectDisplayOrderKey is narrowed to { id, name, sortOrder }.
• GetProjects no longer fetches status.position, because nothing else read it. project list --json loses that field. Make project view show the whole project, add a picker, and order project list like Linear #290 added it and it was never released.
• The status ranking was the only exhaustive check on ProjectStatusType in this command. The date column's switch is now exhaustive instead, so an unknown status type errors rather than silently getting the backlog date. A cross-provider review (Codex) found this gap.
• Tests: the ordering test now uses the observed data above and would fail under the old comparator. The tie-break and non-numeric sortOrder tests are kept. A new test covers an unknown status type. The JSON pagination snapshot now lists Alpha (sortOrder 900, started) before Beta (1000, planned) and has no position.
• The CHANGELOG entry from Make project view show the whole project, add a picker, and order project list like Linear #290 is rewritten in place to describe the new rule. No second entry was added.

Still uncertain

• View settings: it is not yet confirmed whether the app view used for the comparison had a customised grouping or ordering setting. The view URL would show grouping=/ordering= params.
• sortOrder vs prioritySortOrder: the two were identical for every project here, so this data can't tell them apart. This uses sortOrder, which the schema documents as "the sort order for the project within the workspace. Used for manual ordering in list views."