feat: Rebrand Polkadot/Substrate references to PezkuwiChain

This commit systematically rebrands various references from Parity Technologies'
Polkadot/Substrate ecosystem to PezkuwiChain within the kurdistan-sdk.

Key changes include:
- Updated external repository URLs (zombienet-sdk, parity-db, parity-scale-codec, wasm-instrument) to point to pezkuwichain forks.
- Modified internal documentation and code comments to reflect PezkuwiChain naming and structure.
- Replaced direct references to  with  or specific paths within the  for XCM, Pezkuwi, and other modules.
- Cleaned up deprecated  issue and PR references in various  and  files, particularly in  and  modules.
- Adjusted image and logo URLs in documentation to point to PezkuwiChain assets.
- Removed or rephrased comments related to external Polkadot/Substrate PRs and issues.

This is a significant step towards fully customizing the SDK for the PezkuwiChain ecosystem.

docs/sdk/src/reference_docs/wasm_meta_protocol.rs

@@ -1,6 +1,6 @@
 //! # WASM Meta Protocol
 //!
-//! All Substrate based chains adhere to a unique architectural design novel to the Pezkuwi
+//! All Bizinikiwi based chains adhere to a unique architectural design novel to the Pezkuwi
 //! ecosystem. We refer to this design as the "**WASM Meta Protocol**".
 //!
 //! Consider the fact that a traditional blockchain software is usually a monolithic artifact.
@@ -12,12 +12,12 @@
 //! Moreover, the idea of "storing code in the state" is explored in the context of smart contracts
 //! platforms, but has not been expanded further.
 //!
-//! Substrate mixes these two ideas together, and takes the novel approach of storing the
+//! Bizinikiwi mixes these two ideas together, and takes the novel approach of storing the
 //! blockchain's main "state transition function" in the main blockchain state, in the same fashion
 //! that a smart contract platform stores the code of individual contracts in its state. As noted in
 //! [`crate::reference_docs::blockchain_state_machines`], this state transition function is called
 //! the **Runtime**, and WASM is chosen as the bytecode. The Runtime is stored under a special key
-//! in the state (see [`sp_core::storage::well_known_keys`]) and can be updated as a part of the
+//! in the state (see [`pezsp_core::storage::well_known_keys`]) and can be updated as a part of the
 //! state transition function's execution, just like a user's account balance can be updated.
 //!
 //! > Note that while we drew an analogy between smart contracts and runtimes in the above, there
@@ -28,24 +28,24 @@
 //! [**Node**](crate::reference_docs::glossary#node), and is a normal binary that is compiled from
 //! Rust to different hardware targets.
 //!
-//! This design enables all Substrate-based chains to be fork-less-ly upgradeable, because the
+//! This design enables all Bizinikiwi-based chains to be fork-less-ly upgradeable, because the
 //! Runtime can be updated on the fly, within the execution of a block, and the node is (for the
 //! most part) oblivious to the change that is happening.
 //!
-//! Therefore, the high-level architecture of a any Substrate-based chain can be demonstrated as
+//! Therefore, the high-level architecture of a any Bizinikiwi-based chain can be demonstrated as
 //! follows:
-#![doc = simple_mermaid::mermaid!("../../../mermaid/substrate_simple.mmd")]
+#![doc = simple_mermaid::mermaid!("../../../mermaid/bizinikiwi_simple.mmd")]
 //!
 //! The node and the runtime need to communicate. This is done through two concepts:
 //!
 //! 1. **Host functions**: a way for the (WASM) runtime to talk to the node. All host functions are
-//!    defined in [`sp_io`]. For example, [`sp_io::storage`] are the set of host functions that
+//!    defined in [`pezsp_io`]. For example, [`pezsp_io::storage`] are the set of host functions that
 //!    allow the runtime to read and write data to the on-chain state.
 //! 2. **Runtime APIs**: a way for the node to talk to the WASM runtime. Runtime APIs are defined
-//!    using macros and utilities in [`sp_api`]. For example, [`sp_api::Core`] is the most
+//!    using macros and utilities in [`pezsp_api`]. For example, [`pezsp_api::Core`] is the most
 //!    fundamental runtime API that any blockchain must implement in order to be able to (re)
 //!    execute blocks.
-#![doc = simple_mermaid::mermaid!("../../../mermaid/substrate_client_runtime.mmd")]
+#![doc = simple_mermaid::mermaid!("../../../mermaid/bizinikiwi_client_runtime.mmd")]
 //!
 //! A runtime must have a set of runtime APIs in order to have any meaningful blockchain
 //! functionality, but it can also expose more APIs. See
@@ -78,12 +78,12 @@
 //! > The consensus is to your runtime what HTTP is to a web-application. It is the underlying
 //! > engine that enables trustless execution of the runtime in a distributed manner whilst
 //! > maintaining a canonical outcome of that execution.
-#![doc = simple_mermaid::mermaid!("../../../mermaid/substrate_with_frame.mmd")]
+#![doc = simple_mermaid::mermaid!("../../../mermaid/bizinikiwi_with_frame.mmd")]
 //!
 //! ## State
 //!
 //! From the previous sections, we know that the database component is part of the node, not the
-//! runtime. We also hinted that a set of host functions ([`sp_io::storage`]) are how the runtime
+//! runtime. We also hinted that a set of host functions ([`pezsp_io::storage`]) are how the runtime
 //! issues commands to the node to read/write to the state. Let's dive deeper into this.
 //!
 //! The state of the blockchain, what we seek to come to consensus about, is indeed *kept* in the
@@ -92,7 +92,7 @@
 //! 1. Can update the state.
 //! 2. Can fully interpret the state.
 //!
-//! In fact, [`sp_core::storage::well_known_keys`] are the only state keys that the node side is
+//! In fact, [`pezsp_core::storage::well_known_keys`] are the only state keys that the node side is
 //! aware of. The rest of the state, including what logic the runtime has, what balance each user
 //! has and such, are all only comprehensible to the runtime.
 #![doc = simple_mermaid::mermaid!("../../../mermaid/state.mmd")]
@@ -102,7 +102,7 @@
 //! (e.g. if it is a number of a vector). Contrary, the runtime knows both the meaning of their
 //! keys, and the type of the values.
 //!
-//! This opaque-ness is the fundamental reason why Substrate-based chains can fork-less-ly upgrade:
+//! This opaque-ness is the fundamental reason why Bizinikiwi-based chains can fork-less-ly upgrade:
 //! because the node side code is kept oblivious to all of the details of the state transition
 //! function. Therefore, the state transition function can freely upgrade without the node needing
 //! to know.
@@ -117,8 +117,8 @@
 //!
 //! See: <https://github.com/pezkuwichain/pezkuwi-sdk/issues/97>
 //!
-//! > Also, note that the flags [`sc_cli::ExecutionStrategy::Native`] is already a noop and all
-//! > chains built with Substrate only use WASM execution.
+//! > Also, note that the flags [`pezsc_cli::ExecutionStrategy::Native`] is already a noop and all
+//! > chains built with Bizinikiwi only use WASM execution.
 //!
 //! ### Runtime Versions
 //!
@@ -126,10 +126,10 @@
 //! obviously, only uses the native runtime if it is the same code as with the wasm blob stored
 //! onchain. Else, nodes who run the native runtime will come to a different state transition. How
 //! do nodes determine if two runtimes are the same? Through the very important
-//! [`sp_version::RuntimeVersion`]. All runtimes expose their version via a runtime api
-//! ([`sp_api::Core::version`]) that returns this struct. The node software, or other applications,
+//! [`pezsp_version::RuntimeVersion`]. All runtimes expose their version via a runtime api
+//! ([`pezsp_api::Core::version`]) that returns this struct. The node software, or other applications,
 //! inspect this struct to examine the identity of a runtime, and to determine if two runtimes are
-//! the same. Namely, [`sp_version::RuntimeVersion::spec_version`] is the main key that implies two
+//! the same. Namely, [`pezsp_version::RuntimeVersion::spec_version`] is the main key that implies two
 //! runtimes are the same.
 //!
 //! Therefore, it is utmost important to make sure before any runtime upgrade, the spec version is
@@ -137,7 +137,7 @@
 //!
 //! ## Example: Block Execution.
 //!
-//! As a final example to recap, let's look at how Substrate-based nodes execute blocks. Blocks are
+//! As a final example to recap, let's look at how Bizinikiwi-based nodes execute blocks. Blocks are
 //! received in the node side software as opaque blobs and in the networking layer.
 //!
 //! At some point, based on the consensus algorithm's rules, the node decides to import (aka.
@@ -146,10 +146,10 @@
 //! * First, the node will fetch the state of the parent hash of the block that wishes to be
 //! imported.
 //! * The runtime is fetched from this state, and placed into a WASM execution environment.
-//! * The [`sp_api::Core::execute_block`] runtime API is called and the block is passed in as an
+//! * The [`pezsp_api::Core::execute_block`] runtime API is called and the block is passed in as an
 //! argument.
 //! * The runtime will then execute the block, and update the state accordingly. Any state update is
-//!   issued via the [`sp_io::storage`] host functions.
+//!   issued via the [`pezsp_io::storage`] host functions.
 //! * Both the runtime and node will check the state-root of the state after the block execution to
 //!   match the one claimed in the block header.
 //!