fix(ui): sort project dropdown alphabetically

[ASRagab]

Summary

• sort projects alphabetically by name in the shared project selector
• preserve the store's existing project order
• cover the rendered option order with a client regression test

Why

The New Task project's dropdown rendered projects in insertion order, which made larger project lists difficult to scan.

Testing

• full unit suite: 1,912 passed, 24 skipped
• full client suite: 10 passed
• compile, typecheck, lint, and formatting checks
• live frontend smoke test: the New Task dialog displayed alpha, Beta, Zulu while the sidebar retained insertion order

[johannesjo]

Verdict: looks good, merge-ready. No correctness bugs found.

What I verified

Applied the patch locally (worktree restored to clean afterwards):

Check	Result
npm run typecheck	pass
eslint on both changed files	clean
npm run lint:arch (depcruise)	no violations, 447 modules
Client suite (*.client.test.tsx)	3 files / 10 tests pass
Test is a real regression test	confirmed — reverting only ProjectSelect.tsx makes it fail with ["Zulu…", "alpha…", "Beta…"]
Reactivity not broken by the inline sort	confirmed twice (below)

The reactivity question was the only thing that could have been a real bug: each={[...store.projects].sort(...)} looks like it could snapshot once. It doesn't. The Solid babel output compiles it to get each() { return [...store.projects].sort(...) }, and an ad-hoc test confirmed the list re-sorts both when a project is added and when one is renamed — the spread tracks the array, the comparator tracks each name. <For> keys by reference, so option DOM nodes are moved, not rebuilt.

Test style matches ChangedFilesList.client.test.tsx / ReviewProvider.client.test.tsx exactly (disposer stack, replaceChildren, cleanup in afterEach). Importing setStore from ../store/core is correct — store/store doesn't re-export it.

Nits — none blocking

1. Sidebar still renders insertion order (Sidebar.tsx:787 and :987). The PR calls this out as intentional, but it does mean the dropdown and the sidebar now disagree about project order. If the motivation is "long lists are hard to scan," the sidebar has the same problem — and DENSE_SIDEBAR_LIST_THRESHOLD (Sidebar.tsx:431) says long project lists are already expected. Worth a conscious call rather than a side effect.

2. localeCompare with no options is locale-dependent and tertiary-sensitive. Fine in practice, and the test's alpha / Beta / Zulu case passes under default ICU collation. If deterministic + numeric ordering is ever wanted (Project 2 before Project 10), a module-scope new Intl.Collator(undefined, { sensitivity: 'base', numeric: true }) is the upgrade. Not needed today.

3. NewTaskDialog.tsx:554 still defaults to store.projects[0] (insertion-first) when lastProjectId is unset. Not a bug — the <select> binds by id, so the right option is selected and displayed — but "first project" now means two different things depending on where you look.

Caveat

I could not run npm run test:unit in my sandbox (read-only shared node_modules, so Vite can't write its config temp file). The diff touches no unit-tested module, so this is low risk, but the claimed 1,912 passing unit tests are unverified on my end.

[johannesjo]

Thank you very much! <3