RDSC-3785: Document known issue for RDI upgrade from < 1.8.0 to >= 1.8.0

[ZdravkoDonev-redis]

See https://redislabs.atlassian.net/browse/RDSC-3785

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ andy-stark-redis
❌ ZdravkoDonev-redis
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[github-actions]

Staging links:
https://redis.io/docs/staging/RDSC-3785-add-note-for-rdi-1.8.0-upgrade-known-issue/integrate/redis-data-integration/installation/upgrade
https://redis.io/docs/staging/RDSC-3785-add-note-for-rdi-1.8.0-upgrade-known-issue/integrate/redis-data-integration/release-notes/rdi-1-8-0

[Copilot]

Pull Request Overview

This PR adds documentation for a known high-availability upgrade issue when moving RDI from versions below 1.8.0 to 1.8.0 or higher, including symptoms and a manual-cluster-ID workaround.

• Added a Known Issues section in the RDI 1.8.0 release notes describing the HA lock upgrade problem and workaround.
• Inserted a warning block in the upgrade guide with the same issue details and remediation steps.
• Specified how to edit the configmap to set a unique RDI_CLUSTER_ID.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
content/.../release-notes/rdi-1-8-0.md	Documented HA upgrade issue, symptoms, and configmap workaround
content/.../installation/upgrade.md	Added warning for VM HA upgrade issue and manual cluster ID workaround

Comments suppressed due to low confidence (1)

content/integrate/redis-data-integration/release-notes/rdi-1-8-0.md:95

• [nitpick] In this paragraph, mix of "instances" and later "clusters" may confuse readers. Consider using a single term (e.g., always "instances").

When upgrading from RDI < 1.8.0 to RDI >= 1.8.0 in an HA setup, both RDI instances may incorrectly consider themselves active after the upgrade. This occurs because the upgrade process doesn't update the `rdi:ha:lock` value from the legacy `cluster-1` identifier, causing both clusters to assume they are the active cluster.

[andy-stark-redis]

One minor suggestion (Copilot already suggested the other one I was going to add), but otherwise LGTM.

[yaronp68]

please merge stoyan propsals