reposition line about Docker

- avoid it showing up under "When shouldn't I use the `crashpad` backend" in docs searches

Author: JoshuaMoelans

docs/platforms/native/advanced-usage/backend-tradeoffs/index.mdx

@@ -26,6 +26,8 @@ Currently, `crashpad` is the default on all desktop platforms because it
   * cooperation with Epic's Easy Anti-Cheat
   * CMake build scripts (some users use our backend handler forks solely because of this reason)
 
+When your deployment scenario should wait for the `crashpad_handler` to finish its work before a shutdown-after-crash (systemd, Docker), you can enable the option [`crashpad_wait_for_upload`](/platforms/native/configuration/options/#crashpad-wait-for-upload) to delay application shutdown until the upload of the crash report is completed.
+
 ### When shouldn't I use the `crashpad` backend?
 
 Sentry decided on `crashpad` as the default on all platforms because it offers numerous advantages. However, there are use cases where `crashpad` cannot be used or makes distribution or deployment much harder. We provide other backends for situations when
@@ -38,8 +40,6 @@ Sentry decided on `crashpad` as the default on all platforms because it offers n
 
 In the above cases, if you cannot loosen the requirements of your environment, you have to choose an in-process backend (meaning either `breakpad` or `inproc`).
 
-When your deployment scenario should wait for the `crashpad_handler` to finish its work before a shutdown-after-crash (systemd, Docker), you can enable the option [`crashpad_wait_for_upload`](/platforms/native/configuration/options/#crashpad-wait-for-upload) to delay application shutdown until the upload of the crash report is completed.
-
 ### How do I decide between `breakpad` or `inproc`?
 
 Both backends are comparable in how they differ from `crashpad`. However, there are also considerable differences between the two: