fix(external-hash): follow-up review by Anton Trunov

docs.json

@@ -124,6 +124,7 @@
             "pages": [
               "ecosystem/ton-connect/index",
               "ecosystem/ton-connect/manifest",
+              "ecosystem/ton-connect/message-lookup",
               {
                 "group": "Applications (dApps)",
                 "pages": [
@@ -167,7 +168,6 @@
             "group": "RPC providers",
             "pages": [
               "ecosystem/rpc/overview",
-              "ecosystem/rpc/external-normalization",
               "ecosystem/rpc/toncenter"
             ]
           },

ecosystem/rpc/external-normalization.mdx → ecosystem/ton-connect/message-lookup.mdx

@@ -1,5 +1,5 @@
 ---
-title: "External message normalisation"
+title: "Message lookup"
 ---
 
 import { Aside } from "/snippets/aside.jsx";
@@ -8,14 +8,15 @@ import { Aside } from "/snippets/aside.jsx";
 You should never use external message tracking for payment processing purposes. Check out [payment processing](/guidebook/payment) for more details.
 </Aside>
 
+## Introduction
 
-Normalization is a standardization process that converts different representations into a consistent format. While messages across interfaces follow the TL-B scheme, structural differences in implementation sometimes lead to collisions.
+The process of seeking a transaction associated with an `external-in` message is called **message lookup**. It should only be used for better UX to display, for example, the progress of the operation and its result.
 
-To address this, the ecosystem defines a standard that ensures consistent hash calculation. The normalization rules are specified in detail in [TEP-467](https://github.com/ton-blockchain/TEPs/pull/467).
+### Message normalization
 
-**The problem normalization solves:**
+Normalization is a standardization process that converts different external-in message representations into a consistent format. This needs to be done because the structure of external-in messages allows the same message to be constructed in different forms, which results in different possible hashes for the same external message.
 
-Functionally identical messages may differ in how they represent the `src`, `import_fee`, and `init` fields. These variations result in different hashes for messages with equivalent content, which complicates transaction tracking and deduplication.
+To address this, the ecosystem defines a standard that ensures consistent hash calculation. The normalization rules are specified in detail in the [TEP-467 proposal](https://github.com/ton-blockchain/TEPs/pull/467). Message lookup by its normalized hash is already implemented in most TON [RPC providers](/ecosystem/rpc/overview).
 
 **How normalization works:**
 
@@ -26,15 +27,7 @@ The normalized hash is computed by applying the following standardization rules
 3. **InitState (`init`)**: set to an empty value
 4. **Body**: always stored as a reference
 
-# Transaction lookup using external message from TON Connect
-
-This guide shows how to find the transaction associated with an `external-in` message on the TON blockchain.  
-
-## Message normalization
-
-In TON, messages may contain fields like `init`, `src` and `importFee`. These fields should be removed or zeroed out before calculating the message hash, as described in [TEP-467](https://github.com/ton-blockchain/TEPs/blob/8b3beda2d8611c90ec02a18bec946f5e33a80091/text/0467-normalized-message-hash.md).
-
-Use the function below to generate a **normalized message hash**:
+## Transaction lookup using external message from TON Connect
 
 ```ts
 /**