docs: move deduplication_execution_mode upgrade note to 3.1

The feature now ships in 3.1.0, not 2.60. Revert 2.60.md to its
"no special instructions" state and fold the deduplication execution
mode section into 3.1.md.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: Maffooch

docs/content/en/open_source/upgrading/2.60.md

@@ -2,45 +2,6 @@
 title: 'Upgrading to DefectDojo Version 2.60.x'
 toc_hide: true
 weight: -20260601
-description: New deduplication execution mode for import/reimport.
+description: No special instructions.
 ---
-
-## Deduplication execution mode for import/reimport
-
-This release adds a new `deduplication_execution_mode` setting that controls how
-import/reimport deduplication post-processing is dispatched and whether the API
-response waits for it. It can be set per user (profile) and overridden per request
-on the import and reimport endpoints.
-
-Modes:
-
-- `async` (default): deduplication and the rest of post-processing are dispatched
-  to the background and the response returns immediately. This is the historical
-  behavior; nothing changes for existing users.
-- `async_wait`: post-processing is still dispatched to the background, but the
-  request waits for deduplication to finish before responding. As a result the
-  `scan_added` notification and the statistics in the import/reimport response
-  reflect the deduplicated state (findings that turned out to be duplicates are
-  no longer counted/listed as new). JIRA push, product grading and other
-  non-deduplication tasks remain asynchronous and are not awaited.
-- `sync`: import deduplication runs inline in the web request.
-
-The wait in `async_wait` is bounded by the new `DD_DEDUPLICATION_ASYNC_WAIT_TIMEOUT`
-environment variable (default `60` seconds). If no worker picks up the work within
-the timeout, the request responds anyway (degrading to the `async` outcome) rather
-than hanging.
-
-The import/reimport response now also includes a `deduplication_complete` boolean
-indicating whether deduplication had finished by the time the response was produced.
-
-### Relationship to `block_execution`
-
-The existing `block_execution` profile flag is unchanged. It remains the global
-switch that forces **all** of a user's asynchronous tasks (notifications, JIRA
-push, product grading, deduplication, ...) to run in the foreground.
-`deduplication_execution_mode` is independent and narrower — it only affects
-import/reimport deduplication post-processing. A user who has `block_execution`
-enabled continues to get fully synchronous imports; the upgrade migration seeds
-their `deduplication_execution_mode` to `sync` so behavior is unchanged.
-
-No action is required to upgrade. Check the [Release Notes](https://github.com/DefectDojo/django-DefectDojo/releases/tag/2.60.0) for the contents of the release.
+There are no special instructions for upgrading to 2.60.x. Check the [Release Notes](https://github.com/DefectDojo/django-DefectDojo/releases/tag/2.60.0) for the contents of the release.

docs/content/en/open_source/upgrading/3.1.md

@@ -2,10 +2,50 @@
 title: 'Upgrading to DefectDojo Version 3.1.x'
 toc_hide: true
 weight: -20260615
-description: New optional setting DD_OS_MESSAGE_ENABLED to control the open-source promo banner.
+description: New optional setting DD_OS_MESSAGE_ENABLED to control the open-source promo banner, and a new deduplication execution mode for import/reimport.
 ---
 There are no breaking changes when upgrading to 3.1.x. Check the [Release Notes](https://github.com/DefectDojo/django-DefectDojo/releases/tag/3.1.0) for the contents of the release.
 
 ### New setting: `DD_OS_MESSAGE_ENABLED`
 
 This release adds the `DD_OS_MESSAGE_ENABLED` setting (default `True`), which controls the open-source promotional ("Upgrade to Pro") banner. The default preserves the existing behavior. Set `DD_OS_MESSAGE_ENABLED=False` to hide the banner; when disabled, DefectDojo skips the outbound request that fetches the message.
+
+## Deduplication execution mode for import/reimport
+
+This release adds a new `deduplication_execution_mode` setting that controls how
+import/reimport deduplication post-processing is dispatched and whether the API
+response waits for it. It can be set per user (profile) and overridden per request
+on the import and reimport endpoints.
+
+Modes:
+
+- `async` (default): deduplication and the rest of post-processing are dispatched
+  to the background and the response returns immediately. This is the historical
+  behavior; nothing changes for existing users.
+- `async_wait`: post-processing is still dispatched to the background, but the
+  request waits for deduplication to finish before responding. As a result the
+  `scan_added` notification and the statistics in the import/reimport response
+  reflect the deduplicated state (findings that turned out to be duplicates are
+  no longer counted/listed as new). JIRA push, product grading and other
+  non-deduplication tasks remain asynchronous and are not awaited.
+- `sync`: import deduplication runs inline in the web request.
+
+The wait in `async_wait` is bounded by the new `DD_DEDUPLICATION_ASYNC_WAIT_TIMEOUT`
+environment variable (default `60` seconds). If no worker picks up the work within
+the timeout, the request responds anyway (degrading to the `async` outcome) rather
+than hanging.
+
+The import/reimport response now also includes a `deduplication_complete` boolean
+indicating whether deduplication had finished by the time the response was produced.
+
+### Relationship to `block_execution`
+
+The existing `block_execution` profile flag is unchanged. It remains the global
+switch that forces **all** of a user's asynchronous tasks (notifications, JIRA
+push, product grading, deduplication, ...) to run in the foreground.
+`deduplication_execution_mode` is independent and narrower — it only affects
+import/reimport deduplication post-processing. A user who has `block_execution`
+enabled continues to get fully synchronous imports; the upgrade migration seeds
+their `deduplication_execution_mode` to `sync` so behavior is unchanged.
+
+No action is required to upgrade.