Apply suggestions from code review

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>

Author: hfxsd

best-practices/pd-scheduling-best-practices.md

@@ -298,11 +298,7 @@ Practically, if a node failure is considered unrecoverable, you can immediately
 
 Starting from TiDB v5.2.0, TiKV introduces a mechanism to detect slow-disk nodes. By sampling the requests in TiKV, this mechanism works out a score ranging from 1 to 100. A TiKV node with a score higher than or equal to 80 is marked as slow. You can add [`evict-slow-store-scheduler`](/pd-control.md#scheduler-show--add--remove--pause--resume--config--describe) to schedule slow nodes. If only one TiKV node is detected as slow, and its slow score reaches the limit (80 by default), the Leaders on that node will be evicted (similar to the effect of `evict-leader-scheduler`).
 
-<<<<<<< HEAD
-Starting from v8.5.5, TiKV introduces a mechanism to detect slow-network nodes. Similar to slow-disk node detection, this mechanism identifies slow nodes by probing network latency between TiKV nodes and calculating a score. You can enable this mechanism using [`enable-network-slow-store`](/pd-control.md#scheduler-config-evict-slow-store-scheduler).
-=======
-Starting from v8.5.5 and v9.0.0, TiKV introduces a mechanism to detect slow-network nodes. Similar to slow-disk node detection, this mechanism identifies slow nodes by probing network latency between TiKV nodes and calculating a score. You can enable this mechanism using [`enable-network-slow-store`](/pd-control.md#scheduler-config-evict-slow-store-scheduler) (disabled by default).
->>>>>>> dbeacea624 (pd: fix wrong description about `inspect-network-interval` (#22416))
+Starting from v8.5.5, TiKV introduces a mechanism to detect slow-network nodes. Similar to slow-disk node detection, this mechanism identifies slow nodes by probing network latency between TiKV nodes and calculating a score. You can enable this mechanism using [`enable-network-slow-store`](/pd-control.md#scheduler-config-evict-slow-store-scheduler) (disabled by default).
 
 > **Note:**
 >

pd-control.md

@@ -978,19 +978,14 @@ For slow-disk nodes, the detection on TiKV and the scheduling via `evict-slow-st
 
 Starting from v8.5.5, TiKV supports reporting a `NetworkSlowScore` in store heartbeats to PD. It is calculated based on network detection results and helps identify slow nodes experiencing network jitter. The score ranges from 1 to 100, where a higher value indicates a higher possibility of network anomalies.
 
-- TiKV enables detection of slow-network nodes by default, with a default probing interval of `100ms`. To modify the probing frequency, set the TiKV configuration item [`raftstore.inspect-network-interval`](/tikv-configuration-file.md#inspect-network-interval-new-in-v855-and-v900) to an appropriate value. A smaller value increases the probing frequency, which helps detect network jitter more quickly, but also consumes more network and CPU resources.
+- TiKV enables detection of slow-network nodes by default, with a default probing interval of `100ms`. To modify the probing frequency, set the TiKV configuration item [`raftstore.inspect-network-interval`](/tikv-configuration-file.md#inspect-network-interval-new-in-v855) to an appropriate value. A smaller value increases the probing frequency, which helps detect network jitter more quickly, but also consumes more network and CPU resources.
 
 - Scheduling for slow-network nodes is disabled by default on the PD side. To enable it, configure PD as follows:
 
     ```bash
     scheduler config evict-slow-store-scheduler set enable-network-slow-store true
     ```
 
-<<<<<<< HEAD
-2. On TiKV, set the [`raftstore.inspect-network-interval`](/tikv-configuration-file.md#inspect-network-interval-new-in-v855) configuration item to a value greater than `0` to enable network detection.
-
-=======
->>>>>>> dbeacea624 (pd: fix wrong description about `inspect-network-interval` (#22416))
 #### Recovery time control
 
 You can specify how long a slow node must remain stable before it is considered recovered by using the `recovery-duration` parameter.