fix lint

neps/nep-0568.md

@@ -167,7 +167,7 @@ This mapping allows child shards to reference ancestor shard data, avoiding the
 The core of the mapping logic is applied in `TrieStoreAdapter` and `TrieStoreUpdateAdapter`, which act as layers over the general `Store` interface.
 Here’s a breakdown of the key functions involved:
 
-- **Key resolution**:
+* **Key resolution**:
   The `get_key_from_shard_uid_and_hash` function is central to determining the correct `ShardUId` for state access.
   At a high level, operations use the child shard's `ShardUId`, but within this function,
   the `DBCol::ShardUIdMapping` column is checked to determine if an ancestor `ShardUId` should be used instead.
@@ -193,7 +193,7 @@ Here’s a breakdown of the key functions involved:
   If no mapping exists, it defaults to the provided child `ShardUId`.
   This resolved `ShardUId` is then combined with the `node_hash` to form the final key used in `State` column operations.
 
-- **State access operations**:
+* **State access operations**:
   The `TrieStoreAdapter` and `TrieStoreUpdateAdapter` use `get_key_from_shard_uid_and_hash` to correctly resolve the key for both reads and writes.
   Example methods include:
 
@@ -216,13 +216,15 @@ Here’s a breakdown of the key functions involved:
       self.store_update.increment_refcount_by(DBCol::State, key.as_ref(), data, increment);
    }
    ```
+
   The `get` function retrieves data using the resolved `ShardUId` and key, while `increment_refcount_by` manages reference counts,
   ensuring correct tracking even when accessing data under an ancestor shard.
 
 #### Mapping retention and cleanup
 
 Mappings in `DBCol::ShardUIdMapping` persist as long as any descendant relies on an ancestor’s data.
 To manage this, the `set_shard_uid_mapping` function in `TrieStoreUpdateAdapter` adds a new mapping during resharding:
+
 ```rust
 fn set_shard_uid_mapping(&mut self, child_shard_uid: ShardUId, parent_shard_uid: ShardUId) {
     self.store_update.set(