Update migration-guides.adoc (#331)

Fixes the following error 

https://github.com/hazelcast/cloud-docs/actions/runs/10883772749/job/30197635356?pr=160#step:4:26

docs/modules/ROOT/pages/migration-guides.adoc

@@ -29,7 +29,7 @@ We will outline this solution in the <<client-migration, Client Migration sectio
 be it the code using members or client instances. It only migrates the member data and does not provide
 any 3.x compatible API on a 4.x member or client.
 * The tool provides a migration path from a Hazelcast 3.12 cluster to a 4.x cluster,
-not from any previous 3.x versions.
+not from any previous 3.x versions.
 * See also the <<limitations-and-known-issues, Limitations and Known Issues section>> for more
 limitations when using the migration tool.
 ====
@@ -74,7 +74,7 @@ The members of the 3.12 cluster should have a minor version of at least 3.12 (an
 You need to setup WAN replication between the 3.12 and 4.x clusters as stated
 in the 3rd step below.
 2. Next, setup a 4.x cluster. It must have at least one "migration" member and
-all other ("plain") members should be at least 4.0.2.
+all other ("plain") members should be at least 4.0.2.
 The "migration" member can also be a "lite" member while the other "plain" members need not be.
 Making the "migration" member a "lite" member will also simplify further migration steps.
 The exact ratio of "migration" and "plain" members depends on your environment. In some cases
@@ -174,7 +174,7 @@ The 3.12 cluster must have at least one "migration" member and the 4.x cluster m
 at least one "migration" member. The "migration" member can also be a "lite" member while other
 "plain" members need not be. Making the "migration" member a "lite" member will also simplify
 further migration steps. Other "plain" members of the 3.12 cluster can be of any patch version
-and members of the 4.x cluster should be at least 4.0.2.
+and members of the 4.x cluster should be at least 4.0.2.
 The exact ratio of "migration" and "plain" members depends on your environment. In some cases
 it will not be possible to mix members of different "types" (or versions, for example in PCF) and
 in those cases you can create a cluster comprised entirely out of "migration" members. In other
@@ -1383,7 +1383,7 @@ public boolean onLogin() throws LoginException {
     CredentialsCallback cc = new CredentialsCallback();
     try {
         callbackHandler.handle(new Callback[] { cc });
-    } catch (IOException | UnsupportedCallbackException e) {
+    } catch (IOException \| UnsupportedCallbackException e) {
         throw new FailedLoginException("Unable to retrieve credentials. " + e.getMessage());
     }
     Credentials creds = cc.getCredentials();