[Settings] Back up the settings folder before migrating (#7386)

* [Settings] Back up the settings folder before migrating

The per-file settings migration only preserved global.ini, as
global.ini.old. Everything else the migrations write was overwritten in
place with no way back: the legacy migration and the 17 per-domain
migrateXxxSettings functions all write straight into the per-domain .ini
files, so any of them that got a key mapping wrong silently replaced a
working file. The re-migration path is the sharpest case, because
migrateSettingsFromGlobalIni() runs again whenever an older build wrote
non-sentinel keys back into global.ini, and those values then land on
top of per-domain files the user had already edited.

Snapshot the whole settings folder before either migration runs, into a
timestamped sibling settings-backup-<yyyyMMdd-HHmmss>. A sibling rather
than a child, so a backup is never copied into the next backup and the
"Open Settings Folder" action keeps showing only live files. Keep every
snapshot; settings files are kilobytes, so growth is not a concern.

SettingsMigration::isMigrationPending() gates the copy so a normal start
creates nothing. It reuses the same condition migrateSettingsFromGlobalIni()
uses to decide whether it has work, factored into a shared helper so the
two cannot drift, and it ignores the legacy migration on an empty profile
where that migration only writes its sentinel. The backup itself skips a
folder whose files are all empty, which covers a fresh profile whose
global.ini was created but never written.

A failed copy logs a warning and returns an empty path rather than
aborting the migration, since a full disk or an unwritable data folder
must not leave the client unable to start. global.ini.old still works as
the single-file escape hatch.

Document the folder layout, the automatic backups, and the fact that
migrations only run forwards, so users know to copy the settings folder
before downgrading to a version that cannot read the per-group files.

* [Client] Match the desktop file name case for the portal app ID

QGuiApplication::setDesktopFileName() was given "Cockatrice"/"Oracle"
while the installed desktop entries are cockatrice.desktop and
oracle.desktop. Linux paths are case-sensitive, so xdg-desktop-portal
failed the app-info lookup for "Cockatrice" and Qt warned on every
QDesktopServices call that it could not register with the host portal.
The same string becomes the xdg-shell appId, so the window icon lookup
failed on Wayland for the same reason.

---------

Co-authored-by: Lukas Brübach <Bruebach.Lukas@bdosecurity.de>

doc/doxygen/extra-pages/user_documentation/index.md

@@ -11,6 +11,10 @@
 
 - @subpage beta_release
 
+## Settings
+
+- @subpage settings_folder
+
 ## Card Pictures
 
 - @subpage custom_card_pictures

doc/doxygen/extra-pages/user_documentation/settings/settings_folder.md

@@ -0,0 +1,43 @@
+@page settings_folder Settings Folder and Backups
+
+Cockatrice keeps all of its preferences in a settings folder on your computer, one `.ini` file per
+group of settings (appearance, sound, decks, and so on). Open it from the main window via
+Help → Open Settings Folder.
+
+# The Per-File Migration
+
+Older versions of Cockatrice stored every setting in a single `global.ini` file. The settings were
+split into per-group `.ini` files so that unrelated groups no longer share one file. The first time
+you start a version that uses the new layout, your settings are moved into the new files
+automatically and nothing is lost. The old `global.ini` is kept next to the new files as
+`global.ini.old`.
+
+# Automatic Backups
+
+Both migrations overwrite files in the settings folder in place, so before either one runs,
+Cockatrice copies the whole folder to a timestamped backup folder:
+
+```
+<data folder>/settings-backup-20261002-193000/
+```
+
+The backup folder sits next to the settings folder, not inside it. Every backup is kept, so if
+settings ever end up wrong you can compare against, or copy files back from, the earlier snapshot.
+Backups are only created when a migration actually has work to do, so a normal start creates
+nothing.
+
+# Downgrading
+
+Settings migrations only run forwards. If you ever go back to an older version of Cockatrice, that
+version does not read the new per-group files, so it will start with default settings.
+
+Before downgrading, copy your settings folder somewhere safe, for example:
+
+-   Linux: `~/.local/share/Cockatrice/settings/`
+-   macOS: `~/Library/Application Support/Cockatrice/settings/`
+-   Windows: `%LOCALAPPDATA%\Cockatrice\settings\`
+
+Portable installs keep the settings folder in the `data` folder next to the executable.
+
+Copying that folder back after downgrading restores your settings. The automatic backup folder from
+the migration is there as a second copy of the same data if you need it.