[DOCS] Add soft redirect for sliced scroll (#60699)

docs/reference/docs/delete-by-query.asciidoc

@@ -130,7 +130,7 @@ This is "bursty" instead of "smooth".
 [[docs-delete-by-query-slice]]
 ===== Slicing
 
-Delete by query supports <<sliced-scroll, sliced scroll>> to parallelize the
+Delete by query supports <<slice-scroll, sliced scroll>> to parallelize the
 delete process. This can improve efficiency and provide a
 convenient way to break the request down into smaller parts.
 
@@ -487,7 +487,7 @@ Which results in a sensible `total` like this one:
 ===== Use automatic slicing
 
 You can also let delete-by-query automatically parallelize using
-<<sliced-scroll, sliced scroll>> to slice on `_id`. Use `slices` to specify
+<<slice-scroll, sliced scroll>> to slice on `_id`. Use `slices` to specify
 the number of slices to use:
 
 [source,console]

docs/reference/docs/reindex.asciidoc

@@ -187,7 +187,7 @@ timeouts.
 [[docs-reindex-slice]]
 ===== Slicing
 
-Reindex supports <<sliced-scroll>> to parallelize the reindexing process.
+Reindex supports <<slice-scroll>> to parallelize the reindexing process.
 This parallelization can improve efficiency and provide a convenient way to
 break the request down into smaller parts.
 
@@ -257,7 +257,7 @@ which results in a sensible `total` like this one:
 [[docs-reindex-automatic-slice]]
 ====== Automatic slicing
 
-You can also let `_reindex` automatically parallelize using <<sliced-scroll>> to
+You can also let `_reindex` automatically parallelize using <<slice-scroll>> to
 slice on `_id`. Use `slices` to specify the number of slices to use:
 
 [source,console]

docs/reference/docs/update-by-query.asciidoc

@@ -125,7 +125,7 @@ This is "bursty" instead of "smooth".
 [[docs-update-by-query-slice]]
 ===== Slicing
 
-Update by query supports <<sliced-scroll, sliced scroll>> to parallelize the
+Update by query supports <<slice-scroll, sliced scroll>> to parallelize the
 update process. This can improve efficiency and provide a
 convenient way to break the request down into smaller parts.
 
@@ -600,7 +600,7 @@ Which results in a sensible `total` like this one:
 ===== Use automatic slicing
 
 You can also let update by query automatically parallelize using
-<<sliced-scroll>> to slice on `_id`. Use `slices` to specify the number of
+<<slice-scroll>> to slice on `_id`. Use `slices` to specify the number of
 slices to use:
 
 [source,console]

docs/reference/redirects.asciidoc

@@ -1006,6 +1006,16 @@ See <<how-es-highlighters-work-internally>>.
 
 See <<scroll-search-results>>.
 
+[[_clear_scroll_api]]
+===== Clear scroll API
+
+See <<clear-scroll-api>>.
+
+[[sliced-scroll]]
+===== Sliced scroll
+
+See <<slice-scroll>>.
+
 [role="exclude",id="request-body-search-search-after"]
 ==== Search After
 

docs/reference/search/request-body.asciidoc

@@ -149,6 +149,11 @@ See <<scroll-search-results>>.
 
 See <<clear-scroll-api>>.
 
+[[sliced-scroll]]
+===== Sliced scroll
+
+See <<slice-scroll>>.
+
 [[request-body-search-search-after]]
 ==== Search After
 

docs/reference/search/request/scroll.asciidoc

@@ -201,7 +201,7 @@ DELETE /_search/scroll/DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMN
 // TEST[catch:missing]
 
 [discrete]
-[[sliced-scroll]]
+[[slice-scroll]]
 ==== Sliced Scroll
 
 For scroll queries that return a lot of documents it is possible to split the scroll in multiple slices which