`stop_ongoing()` doesn't work if called too soon

- Operating System (Linux/Mac/Windows/iOS/Android): All
- Core Version: 2.59.0
- Client Version: 2.59.1

## Expected behavior

`add_transport` is cancelled.

## Actual behavior

https://github.com/chatmail/core/blob/2cacdbfd4be5f354371a6d7a4867b207e05cef28/src/context.rs#L821

In practice this means that pressing "Cancel" doesn't actually cancel anything.

### Steps to reproduce the problem

1. Call `rpc.add_transport_from_qr`
2. Immediately (or almost immediately) call `stop_ongoing_process`.

The problem is that there are quite a few `await`s before the `alloc_ongoing`.

https://github.com/chatmail/core/blob/fbbe56c8ff6374f630c56b8000a77d0e5d7d8834/src/configure.rs#L133

The biggest one is probably `stop_io`

https://github.com/chatmail/core/blob/fbbe56c8ff6374f630c56b8000a77d0e5d7d8834/src/configure.rs#L160

This bug definitely affects Desktop

https://github.com/deltachat/deltachat-desktop/blob/820deb5fcb0b0f350fce1041122dddad60196948/packages/frontend/src/components/dialogs/ConfigureProgressDialog.tsx#L65-L88

And most likely also Android, but I didn't try:

https://github.com/deltachat/deltachat-android/blob/8a389bdf24c773fc7153bc86088316bdeaa952cb/src/main/java/org/thoughtcrime/securesms/InstantOnboardingActivity.java#L583-L598

I see two options:
- Redesign the API. Such that the user can stop a process by its revocation handle / token / signal. Can be either a parameter provided to `add_transport` or its return value (although `add_transport` doesn't return until it's finished).
- Offload the problem to users (client devs). Tell them in the docs that they need to wait for at least one `ConfigureProgress` (or whatever else) event before they can call `stop_ongoing`.

Start with the add_transport_from_qr and stop_ongoing_process entry points in src/configure.rs and src/context.rs, focusing on alloc_ongoing and stop_io. Review the Desktop and Android call sites to understand the cancellation contract; done means an immediate stop reliably cancels add_transport, after the project agrees on an API or client-side approach.

Written by the indexing model from the issue text.