feat: add blockchain sharding and hypercube routing page

[Karkarmath]

Closes #232

[github-actions]

To fix the formatting issues:

1. Install necessary dependencies: npm ci
2. Then, run this command:

npx remark -o --silent --silently-ignore foundations/shards.mdx 

[github-actions]

Thanks for the updates to the shards documentation. I found a few high‑impact items in the foundations doc that need fixes before merge.

Findings (3)

High (3)

[HIGH] Silent truncation of addresses in examples

Location:

docs/foundations/shards.mdx

Lines 92 to 101 in 220eb6b

	For example, suppose that a message has source (hence, first transit) address with `workchain_id` equal to `0` and `account_id` equal to `0x1234567890ABCDEF...`, and destination address with `workchain_id` equal to `0` and `account_id` equal to `0x12345678FEDCBA98...`.
	Then the first next-hop address will have `workchain_id` equal to `0` and `account_id` equal to `0x12345678F0ABCDEF...`.
	Here comes an key definition for routing protocol: two shardchains are said to be _neighbors_, or _neighboring shardchains_,
	if one of them contains a next-hop address for at least one combination of allowed source and destination addresses, while the other
	contains the transit address for the same combination. In other words, two shardchains are neighbors if a message can be forwarded directly from one
	of them into the other via routing algorithm.
	For instance, the shardchains from the previous example that contains the addresses `0:1234567890ABCDEF...` and `0:12345678F0ABCDEF...` are neighbors, because a message with source address `0:1234567890ABCDEF...` and destination address `0:12345678FEDCBA98...`
	will be rorwarded directly from the first shardchain into the second one.

Description:
Several examples show truncated addresses and IDs using "…" without explicitly noting truncation (e.g., 0x1234567890ABCDEF..., 0:1234567890ABCDEF...). The extended style guide forbids silent truncation; readers may copy/paste or attempt verification and be misled.

Suggestion:
Add a clear disclosure note after the first example.

@@
-Then the first next-hop address will have `workchain_id` equal to `0` and `account_id` equal to `0x12345678F0ABCDEF...`.
+Then the first next-hop address will have `workchain_id` equal to `0` and `account_id` equal to `0x12345678F0ABCDEF...`.
+
+Note: example addresses shown with "..." are truncated for readability and are not intended for copy/paste.

Alternatively, append “(truncated)” after each truncated value.

-For example, suppose that a message has source (hence, first transit) address with `workchain_id` equal to `0` and `account_id` equal to `0x1234567890ABCDEF...`, and destination address with `workchain_id` equal to `0` and `account_id` equal to `0x12345678FEDCBA98...`.
+For example, suppose that a message has source (hence, first transit) address with `workchain_id` equal to `0` and `account_id` equal to `0x1234567890ABCDEF...` (truncated), and destination address with `workchain_id` equal to `0` and `account_id` equal to `0x12345678FEDCBA98...` (truncated).

-Then the first next-hop address will have `workchain_id` equal to `0` and `account_id` equal to `0x12345678F0ABCDEF...`.
+Then the first next-hop address will have `workchain_id` equal to `0` and `account_id` equal to `0x12345678F0ABCDEF...` (truncated).

-For instance, the shardchains from the previous example that contains the addresses `0:1234567890ABCDEF...` and `0:12345678F0ABCDEF...` are neighbors, because a message with source address `0:1234567890ABCDEF...` and destination address `0:12345678FEDCBA98...`
+For instance, the shardchains from the previous example that contains the addresses `0:1234567890ABCDEF...` (truncated) and `0:12345678F0ABCDEF...` (truncated) are neighbors, because a message with source address `0:1234567890ABCDEF...` (truncated) and destination address `0:12345678FEDCBA98...` (truncated)

Or, use a consistent first‑4/last‑4 pattern and inline disclosure.

@@
-For instance, the shardchains from the previous example that contains the addresses `0:1234567890ABCDEF...` and `0:12345678F0ABCDEF...` are neighbors, because a message with source address `0:1234567890ABCDEF...` and destination address `0:12345678FEDCBA98...`
-will be rorwarded directly from the first shardchain into the second one.
+For instance, the shardchains from the previous example that contains the addresses `0:1234…CDEF` and `0:1234…CDEF` are neighbors (addresses shown are truncated for readability), because a message with source address `0:1234…CDEF` and destination address `0:1234…BA98`
+will be rorwarded directly from the first shardchain into the second one.

[HIGH] Missing import for <Image> component

Location:

docs/foundations/shards.mdx

Lines 21 to 25 in 220eb6b

	<Image
	src="/resources/images/blockchain_sharding.png"
	darkSrc="/resources/images/blockchain_sharding.png"
	alt="Blockchain hyerarchy"
	/>

Description:
The page uses the <Image> component but does not import it. In this MDX setup, components must be explicitly imported; otherwise the page fails to compile or render.

Suggestion:
Add the missing import immediately after the frontmatter.

--- a/foundations/shards.mdx
+++ b/foundations/shards.mdx
@@
 title: "Blockchain sharding"
 ---
 
+import { Image } from '/snippets/image.jsx';
+
 ## Infinite Sharding Paradigm

[HIGH] Callout uses unsupported component

Location:

docs/foundations/shards.mdx

Lines 103 to 105 in 220eb6b

	<Note>
	Regarding the definition, each sharcshain is a neigbor of itself and the single shardchain in the masterchain is a neigbor for every shardchain.
	</Note>

Description:
The docs system does not support <Note>; callouts should use <Aside> with supported type values. Using unsupported components risks inconsistent rendering.

Suggestion:
Replace <Note> with <Aside type="note">.

-<Note>
-Regarding the definition, each sharcshain is a neigbor of itself and the single shardchain in the masterchain is a neigbor for every shardchain.
-</Note>
+<Aside type="note">
+Regarding the definition, each sharcshain is a neigbor of itself and the single shardchain in the masterchain is a neigbor for every shardchain.
+</Aside>

[anton-trunov]

Please see the comment.

[verytactical]

MN from a review call

Goal:

• tell reader, how many hops it takes to deliver a message
• explain why it's needed: reduce latency for complex protocols, especially those that involve contracts sharding (Jetton, DEX)

Plan:
Reduce part of the article starting with "Intermediate addresses" with something more simple.

Two images:

• a cube grid, show hops along axes on it
• two addresses, their shard_prefix parts in black, rest of the bits in gray, show groups of n2=4 bits, show which are distinct and count towards hop count

Use first image to explain how hypercube routing works in general. Use second image + mention of extraworkchain_id hop to explain hop counting.
Tell how to use lt (or whatever) on an explorer to see what hop count was.

[github-actions]

Thanks for the update—there are a couple of suggestions in foundations/shards.mdx; please apply the inline suggestions to address them.