Disclosure: FireKey team here. This is an AI-assisted source review, not a reproduction on the reported nightly.
The current main implementation is consistent with your report:
reportProfilesnormalizes only the incoming list and replaces the singlereportedProfilesvalue, includingdefaultProfileId.resolveOpenProfilerejects an ID missing from that catalog. Existing storage does not participate in this lookup, so this error alone does not establish that the saved session was deleted.
One extra edge case worth covering: even if the lists are merged, a later report can still switch the default used by preview_open when no profileId is supplied. A shared catalog and a client's preferred default need separate ownership semantics; retaining X in the catalog does not by itself prevent an implicit open from selecting Y.
The existing profile-selection test looks like a useful place to add a sequence: A reports {X,Y} with default X, B reports {Y} with default Y, then A/B report again. Check explicit X lookup, deduplication of Y by stable ID, and the intended default after each step.
For any merge-based fix, omission should not silently double as deletion. Explicit removal needs defined behavior so a stale reconnect cannot resurrect a removed profile. That distinction also matters if the server discovers profiles from disk: directory existence gives an ID, not necessarily the current name/default/deletion state. No patch or runtime test is included here.
