fix the review's findings and cut the remaining API surface

Correctness.

The one-time link picker's profile list was keyed on the active user as well as the
count. That defeats the "don't change order after a user was selected" behaviour its own
comment protects - changeActiveUser_ sets currentUser first and only then reloads chats,
so the list visibly re-sorted and stayed re-sorted for the whole of getUserChatData - and
it was redundant: the count alone covers a profile being created from the picker.

iOS, compose picker: the old-core fallback relied on the user switch tearing this view
down, which only happens when the switch succeeded. If it threw, the form was left open
over a profile that already existed, and the only way out was to swipe it away. It is now
dismissed unconditionally.

iOS: alerts raised right after a sheet is dismissed are presented on a controller that is
going away and are dropped. The 0.5s wait was applied only to the old-core path, while the
ordinary reassignment failures - the ones that actually happen - went unguarded.
alertAfterDismissal now covers all of them, in one place.

iOS: dropped the chatId write that Kotlin removed for the same reason two commits ago. It
is a no-op on the happy path, but not if something legitimately closed the chat meanwhile
- SimpleX lock re-auth clears it, and this would reopen the chat behind the lock screen.

iOS: the create-profile row is now gated on profileChangeProhibited, as every other row on
both platforms already was.

Surface.

apiCreateActiveUser takes keepActiveUser as a defaulted argument, exactly as it already
takes pastTimestamp, instead of a public wrapper plus a private helper. Two symbols fewer
on each platform, and every existing call site passes its arguments by name, so none of
them changes.

Reverted the activeOrder sort flip in the compose picker: it changes the order of an
existing screen for every user, is not needed for this feature, and with active_order 0
would push a newly created profile to the bottom. It deserves its own commit if wanted.

Also: apps/ios/spec/api.md tracks the command enum and had gone stale; the plan records
the two limits of the flag the review surfaced - it is ignored when there is no active
user, and active_order 0 ties rather than sorts last on migrated databases.

plans/2026-07-30-new-profile-for-invitation.md

@@ -72,6 +72,17 @@ window with the opposite outcome.
 and older callers are untouched. The flag is ignored when there is no active user to keep,
 which would otherwise leave none at all.
 
+Two limits of the flag, both deliberate and neither covered by a test:
+
+- It is **ignored when there is no active user** (`isNothing curUser_`), which would
+  otherwise leave none at all. A client cannot distinguish that from a stale host that
+  dropped the field — both come back as `activeUser = True`.
+- `active_order = 0` for a profile that was never activated sorts it **below** activated
+  ones, but `M20240920_user_order` back-filled every existing row with 0, so on a migrated
+  database it *ties* with them and the order falls back to row order. `userQuery` has no
+  `ORDER BY`, and the terminal harness cannot observe `activeOrder`, so this is stated
+  rather than tested.
+
 Response stays `CRActiveUser` — it carries the created user, which on this path is not
 the active one. Documented at the field; no client decoder changes.