Project list and workspace details show different conversation counts; workspace load still slow on large installs

[bradjin8]

Problem

After #88 (lazy-load + summary endpoints), two correctness issues and one performance gap remain on large Cursor installs:

1. Count mismatch — The project list page shows a different conversationCount than the number of tabs on the workspace details page for the same project.
2. Noisy logs — Loading workspace summaries logs warnings for composerData:empty-state-draft when the global KV row has a NULL payload (the JSON object must be str, bytes or bytearray, not NoneType).
3. Slow first paint — On machines with many workspaceStorage folders, project list and sidebar summary still take ~50s because composer ownership was rebuilt sequentially from local state.vscdb files, and some paths still over-fetched global composerData.

Expected behavior

• Project card conversationCount matches GET /api/workspaces/<id>/tabs?summary=1 tab count for the same project.
• Cursor UI placeholders (e.g. empty-state-draft) are skipped without decode warnings.
• Project list and sidebar summary use workspace-scoped I/O with cached composer registry; first conversation auto-loads after sidebar render (~2s is acceptable).

Root cause (count mismatch)

Project list briefly counted conversations from local allComposers without applying the same global filters as the summary path (non-empty fullConversationHeadersOnly, composer validation, exclusion rules including model names).

Acceptance criteria

• conversationCount on project cards equals summary tab count for the same workspace
• No warnings for null/empty composerData placeholders
• Parallel local registry build + scoped global fetches for list/summary paths
• Regression tests for count alignment, workspace scope, and null payload handling
• Workspace UI auto-selects first tab when no ?tab= query param