Update deleted repos known issue language (#37237)

Co-authored-by: Nick Freiter <52747882+ngfreiter@users.noreply.github.com>
Co-authored-by: Jules <19994093+jules-p@users.noreply.github.com>

data/release-notes/enterprise-server/3-6/14.yml

@@ -8,7 +8,7 @@ sections:
     - On an instance in a cluster configuration, when upgrading the MySQL master node, the post-upgrade configuration run would take 600 seconds longer than required due to incorrect detection of unhealthy nodes. 
     - In some situations on an instance with multiple nodes, Git replication failed to fully replicate repositories that had previously been deleted, which resulted in a warning in `ghe-repl-status` output. 
     - If a user clicked the link to share feedback or report bugs for the beta of user lists, the web interface responded with a `404` error. 
-    - If an instance had tens of thousands of deleted repositories, an upgrade to GitHub Enterprise Server 3.7 could take longer than expected. 
+    - If an instance had tens of thousands of deleted repositories, an upgrade to GitHub Enterprise Server 3.6 could take longer than expected. 
     - GitHub Enterprise Server published distribution metrics that cannot be processed by collectd. The metrics included `pre_receive.lfsintegrity.dist.referenced_oids`, `pre_receive.lfsintegrity.dist.unknown_oids`, and `git.hooks.runtime`. 
   changes:
     - People with administrative SSH access to an instance can configure the maximum memory usage in gigabytes for Redis using `ghe-config redis.max-memory-gb VALUE`. 
@@ -35,3 +35,4 @@ sections:
       If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using `ghe-ssl-ca-certificate-install` are not respected, and connections to the server fail.
     - |
       When running `ghe-config-apply`, the process may stall with the message `Deployment is running pending automatic promotion`.
+    - '{% data reusables.release-notes.slow-deleted-repos-migration-known-issue-updated %}'

data/release-notes/enterprise-server/3-7/11.yml

@@ -7,6 +7,7 @@ sections:
   bugs:
     - On an instance in a cluster configuration, when upgrading the MySQL master node, the post-upgrade configuration run would take 600 seconds longer than required due to incorrect detection of unhealthy nodes. 
     - In some situations on an instance with multiple nodes, Git replication failed to fully replicate repositories that had previously been deleted, which resulted in a warning in `ghe-repl-status` output. 
+    - If an instance had tens of thousands of deleted repositories, an upgrade to GitHub Enterprise Server 3.7 could take longer than expected.
     - On an instance with the dependency graph enabled, the correct path appears for manifests that originate from build-time submission snapshots. 
   changes:
     - People with administrative SSH access to an instance can configure the maximum memory usage in gigabytes for Redis using `ghe-config redis.max-memory-gb VALUE`. 
@@ -31,3 +32,4 @@ sections:
       If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using `ghe-ssl-ca-certificate-install` are not respected, and connections to the server fail.
     - |
       When running `ghe-config-apply`, the process may stall with the message `Deployment is running pending automatic promotion`.
+    - '{% data reusables.release-notes.slow-deleted-repos-migration-known-issue-updated %}'

data/reusables/release-notes/slow-deleted-repos-migration-known-issue-updated.md

@@ -0,0 +1 @@
+An upgrade to {% data variables.product.prodname_ghe_server %} 3.6 or 3.7 from 3.5 or earlier may be long running if a large number of deleted repositories exist. The performance of this upgrade has been improved in 3.6.14 and 3.7.11, however if you have tens of thousands of recently deleted repositories the upgrade could still take multiple hours. Deleted repositories are purged automatically after 90 days, but for a faster upgrade they can be purged manually. If you suspect you have tens of thousands of recently deleted repositories, and you are concerned about a long running upgrade, [contact GitHub Enterprise Support](/support/contacting-github-support/creating-a-support-ticket) for assistance purging deleted repositories. [Updated: 2023-05-30]