Pre-existing bug (present on master, independent of any feature work — surfaced while reviewing the QR-type-recognition change but does not depend on it).

Problem

MigrateToDevice.checkUserLink gates on strHasSimplexFileLink(link.trim()) and stores link.trim() in every MigrationToState payload, but passes the raw, untrimmed link to MigrationFileLinkData.readFromLink:

return if (strHasSimplexFileLink(link.trim())) {   // trimmed
  val data = MigrationFileLinkData.readFromLink(link)   // RAW
  ...

readFromLink sends the string into the core as /_download info <link>. With leading whitespace the core's FileDescriptionURI parser fails, readFromLink returns null, and the link's network configuration is silently dropped — the migration then proceeds with the device's own host modes (getNetCfg()) instead of the link's, and the onion screen that the link's proxy config would have triggered is skipped.

The link still downloads (the actual download uses link.trim() from the MigrationToState payload), so the failure is silent: no error, just the wrong network settings applied.

• Only leading whitespace triggers it. Trailing whitespace is harmless because the core right-strips every command line before parsing.
• Android + desktop (the Kotlin multiplatform UI). iOS is unaffected: its readFromLink is a no-op stub that never reads networkConfig.

Fix

Compute val trimmed = link.trim() once and use it for the gate, readFromLink, and every payload — so classification and consumption see the same string and the raw/trimmed split cannot reappear. The only behavioural change is readFromLink now receiving the trimmed link.

How to reproduce manually

Preconditions

• Two devices/profiles, or a reviewer able to produce a migration link. The link must carry proxy/onion network config for the difference to be screen-visible, so on the source device enable a SOCKS proxy / onion host mode for the migration before exporting (Network & servers → onion/SOCKS settings), then start Migrate to another device to obtain the link.
• Target device on Android, or desktop (desktop reaches this code via the paste path; the scanner is Android-only).

A — control (unpadded link)

1. Copy the migration link to the clipboard exactly as produced, with no surrounding whitespace.
2. On the target: Migrate from another device → Tap to paste link.
3. Observe: the onion screen appears (the link's proxy config is applied).

B — trigger (leading whitespace)

1. Take the same link and prepend a single space or a newline (e.g. paste it into a note, add a leading space, copy again — or copy from a source that includes a leading newline).
2. On the target: Migrate from another device → Tap to paste link.
3. Observe on master: the onion screen is skipped; migration goes straight to database init using the device's default host modes. The link's network config is silently lost.

Expected (and result with this fix): B behaves identically to A — the onion screen appears and the link's network config is applied, because leading whitespace is trimmed before the config is read.

Scope

One file, apps/multiplatform/.../views/migration/MigrateToDevice.kt. No string, core, or API changes.