[DOCS][Transform] document limitation regarding rolling upgrade with …

…7.2, 7.3 (#48118)

adds a limitation about rolling upgrade from 7.2 or 7.3. and fixes a problem with renamed preferences

docs/reference/transform/limitations.asciidoc

@@ -33,6 +33,14 @@ upgrade from 7.2 to a newer version, and {transforms} have been created in 7.2,
 the {transforms} UI (earler {dataframe} UI) will not work. Please wait until all 
 nodes have been upgraded to the newer version before using the {transforms} UI.
 
+[float]
+[[transform-rolling-upgrade-limitation]]
+==== {transforms-cap} reassignment suspended during a rolling upgrade from 7.2 and 7.3
+
+If your cluster contains mixed version nodes, for example during a rolling
+upgrade from 7.2 or 7.3 to a newer version, {transforms} whose nodes are stopped will
+not be reassigned until the upgrade is complete. After the upgrade is done, {transforms}
+resume automatically; no action is required.
 
 [float]
 [[transform-datatype-limitations]]
@@ -181,9 +189,9 @@ for the {transform} checkpoint to complete.
 
 [float]
 [[transform-scheduling-limitations]]
-==== {cdataframe-cap} scheduling limitations
+==== {ctransform-cap} scheduling limitations
 
-A {cdataframe} periodically checks for changes to source data. The functionality 
+A {ctransform} periodically checks for changes to source data. The functionality
 of the scheduler is currently limited to a basic periodic timer which can be 
 within the `frequency` range from 1s to 1h. The default is 1m. This is designed 
 to run little and often. When choosing a `frequency` for this timer consider 
@@ -206,7 +214,7 @@ When using the API to delete a failed {transform}, first stop it using
 
 [float]
 [[transform-availability-limitations]]
-==== {cdataframes-cap} may give incorrect results if documents are not yet available to search
+==== {ctransforms-cap} may give incorrect results if documents are not yet available to search
 
 After a document is indexed, there is a very small delay until it is available 
 to search.