docs: add upgrade note

Author: valentijnscholten

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

@@ -5,6 +5,10 @@ weight: -20251006
 description: MobSF parsers & Helm chart changes.
 ---
 
+## Deduplication fix of `UNIQUE_ID_OR_HASH_CODE`
+A bug was fixed in the `UNIQUE_ID_OR_HASH_CODE` algorithm where it stopped processing candidate findings with equal `unique_id_from_tool` or `hash_code` value.
+Strictly speaking this is not a breaking change, but we wanted to make you aware that you can see more (better) more deduplicatation for parsers using this algorithm.
+
 ## Merge of MobSF parsers
 
 Mobsfscan Scan" has been merged into the "MobSF Scan" parser. The "Mobsfscan Scan" scan_type has been retained to keep deduplication working for existing Tests, but users are encouraged to move to the "MobSF Scan" scan_type.
@@ -17,16 +21,16 @@ This release introduces more important changes to the Helm chart configuration:
 
 #### Tags
 
-`tag` and `repositoryPrefix` fields have been deprecated. Currently, image tags used in containers are derived by default from the `appVersion` defined in the Chart.  
-This behavior can be overridden by setting the `tag` value in `images.django` and `images.nginx`.  
-If fine-tuning is necessary, each container’s image value can also be customized individually (`celery.beat.image`, `celery.worker.image`, `django.nginx.image`, `django.uwsgi.image`, `initializer.image`, and `dbMigrationChecker.image`).  
+`tag` and `repositoryPrefix` fields have been deprecated. Currently, image tags used in containers are derived by default from the `appVersion` defined in the Chart.
+This behavior can be overridden by setting the `tag` value in `images.django` and `images.nginx`.
+If fine-tuning is necessary, each container’s image value can also be customized individually (`celery.beat.image`, `celery.worker.image`, `django.nginx.image`, `django.uwsgi.image`, `initializer.image`, and `dbMigrationChecker.image`).
 Digest pinning is now supported as well.
 
 #### Security context
 
 This Helm chart extends security context capabilities to all deployed pods and containers.
 You can define a default pod and container security context globally using `securityContext.podSecurityContext` and `securityContext.containerSecurityContext` keys.
-Additionally, each deployment can specify its own pod and container security contexts, which will override or merge with the global ones. 
+Additionally, each deployment can specify its own pod and container security contexts, which will override or merge with the global ones.
 
 #### Fine-grained resources