feat(fuse,core,cli,gui): move another computer's backup to this one

A user switching from a Windows PC to Linux had two half answers:
adopting the old device makes this machine back up as it, and restoring
its folders keeps them in the old device's tree. Neither puts the data
under this machine's own device.

Device roots are separate shares on the main volume, so each top-level
folder of the other device can move under this device's root in one
server-side move. Nothing is uploaded again, and the other device stays
registered, without those folders.

- core: `Request::MigrateDevice { uid }` and
  `Db::sync_folder_set_share`
- fuse: `Core::migrate_device` moves every folder, suffixes a name
  already taken here with the other device's name, keeps going past a
  failed folder, and re-points sync folders that already tracked a
  moved folder at the new share
- cli: `pdfs devices migrate UID [--yes]` confirms, moves, then runs
  the ordinary restore picker
- gui: "Move to This Computer…" on another computer's row, followed by
  the restore picker
- i18n: translate the new strings in every catalog
- docs: CLI.md, USER_GUIDE.md, RECOVERY.md, ARCHITECTURE.md, changelog

docs/ARCHITECTURE.md

@@ -377,6 +377,12 @@ Restore lists the device's folders, proposes a local path from the profile, and
 adds a synced folder bound to the remote uid. The download is an ordinary pass against an empty
 baseline. The user side is in [RECOVERY.md](RECOVERY.md).
 
+`Core::migrate_device` moves another device's top-level folders under this machine's device root.
+Device roots are separate shares on the main volume, so each folder is one server-side move that
+keeps its uid. A name already taken here gets the other device's name as a suffix. A synced folder
+that already tracked one of them keeps its `remote_uid` and only has its `remote_share_id`
+re-pointed. The moved folders are then offered by the ordinary restore.
+
 ---
 
 ## 8. Control protocol