perf(threads): index thread lookups by id

[Yevanchen]

Closes YEF-942

Summary

• Add a memoized thread id index in the thread query model.
• Reuse that index for selected-thread lookup and pin/archive/delete action lookups.

Why

• The complexity optimizer scan flagged repeated thread-route lookup work.
• This changes repeated thread id lookup from O(n) array scans to O(1) map reads while preserving the sorted thread array used for rendering.

Verification

• Commands:
  • just fmt-check-path apps/web/src/routes/threads
  • just tc-package @mosoo/web
  • just test-package @mosoo/web
• Manual steps: N/A
• Not run: just check because this is a scoped web model change and the web formatting, type-check, and package tests passed.

Impact

• User/API/contract changes: No contract or visible behavior changes expected.
• Generated files / GraphQL / DB / lockfile: None.
• Env or config changes: None.
• Risk and rollback: Low; rollback restores the previous array lookup path.

Review

• Closest review areas: apps/web/src/routes/threads/model/use-queries.ts, apps/web/src/routes/threads/model/use-actions.ts, apps/web/src/routes/threads/controller.tsx
• Known trade-offs: Keeps one O(n) map build per thread-list recompute in exchange for O(1) selected/action lookups.

[Yevanchen]

Review verdict: no measured bottleneck, and this overlaps #482. The API caps the view at 100 active plus 100 archived Threads. On Bun, a worst-case find over 200 entries measured about 0.72 microseconds; building the Map plus one lookup measured about 8.12 microseconds, while Map.get alone measured about 0.013 microseconds. These are not user-visible numbers. Please keep one PR only and provide a real render trace before adding an index.