apply suggestion

Author: JoshuaMoelans

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

@@ -28,8 +28,9 @@ 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), in Linux environments since SDK version [0.8.3](https://github.com/getsentry/sentry-native/releases/tag/0.8.3), 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.
-
+<Alert>
+When your deployment scenario should wait for the `crashpad_handler` to finish its work before a shutdown-after-crash (systemd, Docker), in Linux environments since SDK version [0.8.3](https://github.com/getsentry/sentry-native/releases/tag/0.8.3), 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.
+</Alert>
 ### 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