[Bug] Desktop app update silently deleted all custom sidebar session groups (legacy group migration)

Summary

After the Claude desktop app auto-updated overnight (installed on relaunch 2026-07-19 ~10:08 local), all five of my custom sidebar session groups disappeared. Creating new groups still works, so the feature is intact; the migration of existing groups to the new storage format is what failed. No user action was involved: groups were present the day before, the auto-updater (ShipIt) ran overnight, and on first launch of the new version the groups were gone.

Environment

• Claude desktop (macOS): 1.22209.3, bundled Claude Code 2.1.215
• Previous version: unknown (silent auto-update; ShipIt staged 2026-07-18 22:32, installed 2026-07-19 10:08)
• macOS: Darwin 25.5.0 (Apple Silicon)

Evidence from local state

1. claude_desktop_config.json → preferences.epitaxyPrefs["dframe-group-scopes"] (the new per-account group store) contains ONLY the group created after the update. The five pre-update groups are absent.
2. The sidebar pane state (desktop-frame.paneStore.v1 in Local Storage) still lists all five old group IDs in its collapsedGroups array (entries of the form custom-cg-<uuid>), orphaned: they reference groups that no longer exist in any store. This shows the groups existed pre-update and only the group definitions/assignments were lost.
3. The same pane state contains "pendingLegacyGroupMigration": null and a customGroupsByScope map holding only the post-update group, suggesting a legacy→scoped migration ran and dropped the legacy data.
4. An older LevelDB SSTable that survived compaction still contains the legacy-format data under LSS-persisted.dframe-local-slice: a customGroups array (five {id, name} entries) plus customGroupAssignments and customGroupOrder maps keyed code:local_<session-uuid> → cg-<uuid>. This is the data the migration should have carried into dframe-group-scopes but didn't.

Impact

• Complete loss of user-created sidebar organization (5 groups, 13 session assignments in my case), with no error, no notice, and no built-in way to recover.
• Because the migration also appears to have run during/after LevelDB compaction, the pre-update state is unrecoverable for most users (mine was only reconstructable from an old un-compacted SSTable).

Expected

Legacy custom groups (customGroups / customGroupAssignments / customGroupOrder in dframe-local-slice) migrate into the new scoped store (dframe-group-scopes / customGroupsByScope) on first launch of the new version. If migration cannot resolve the scope (account/org id not yet known at migration time?), it should defer (that seems to be what pendingLegacyGroupMigration is for) rather than complete with data loss.

Hypothesis

The migration ran before the account/org scope key (<accountId>/<orgId>) was available, or matched zero groups against the new scope and marked migration complete (pendingLegacyGroupMigration: null), discarding the legacy data. The orphaned collapsedGroups entries were left behind because that array lives outside the migrated keys.

Happy to provide the recovered legacy JSON blobs or any other local state on request.