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.

pezkuwi/roadmap/implementers-guide/src/node/disputes/dispute-coordinator.md

@@ -176,7 +176,7 @@ current authority set will overlap with the ones in the previous set and will be
 
 Still, for maximum accountability we need to make sure a previous authority set can communicate votes to the next one,
 regardless of any chain: This is yet to be implemented see section "Resiliency" in dispute-distribution and
-[this](https://github.com/paritytech/polkadot/issues/3398) ticket.
+[this](https://github.com/pezkuwichain/kurdistan-sdk/issues/144) ticket.
 
 ## Coordinating Actual Dispute Participation
 
@@ -271,7 +271,7 @@ ordering as the priority one - by block heights of the relay parent, older block
 possibility not to be able to obtain the block number of the parent when we are inserting the dispute in the queue. To
 account for races, we will promote any existing participation request to the priority queue once we learn about an
 including block. NOTE: this is still work in progress and is tracked by [this
-issue](https://github.com/paritytech/polkadot/issues/5875).
+issue](https://github.com/pezkuwichain/kurdistan-sdk/issues/161).
 
 ### Abandoned Forks
 
@@ -468,7 +468,7 @@ finalized in the first place. Not allowing disputing already finalized blocks ac
 as it massively reduces the amount of candidates that can be disputed.
 
 This makes attempts to overwhelm the system with disputes significantly harder and counter measures way easier. We can
-limit inclusion for example (as suggested [here](https://github.com/paritytech/polkadot/issues/5898) in case of high
+limit inclusion for example (as suggested [here](https://github.com/pezkuwichain/kurdistan-sdk/issues/162) in case of high
 dispute load. Another measure we have at our disposal is that on finality lag block production will slow down,
 implicitly reducing the rate of new candidates that can be disputed. Hence, the cutting-off of the unlimited candidate
 supply of already finalized blocks, guarantees the necessary DoS protection and ensures we can have measures in place to

pezkuwi/roadmap/implementers-guide/src/node/disputes/dispute-distribution.md

@@ -202,8 +202,8 @@ the dispute-coordinator already knows about the dispute.
 
 Goal 3 and 4 are obviously very related and both can easily be solved via rate
 limiting as we shall see below. Rate limits should already be implemented at the
-Substrate level, but [are not](https://github.com/paritytech/substrate/issues/7750)
-at the time of writing. But even if they were, the enforced Substrate limits would
+Bizinikiwi level, but [are not](https://github.com/pezkuwichain/kurdistan-sdk/issues/30)
+at the time of writing. But even if they were, the enforced Bizinikiwi limits would
 likely not be configurable and thus would still be to high for our needs as we can
 rely on the following observations:
 
@@ -246,7 +246,7 @@ This is probably an argument for not imposing a too low rate limit, although the
 issue is more general: Even without any rate limit, if an attacker generates
 disputes at a very high rate, nodes will be having trouble keeping participation
 up, hence the problem should be mitigated at a [more fundamental
-layer](https://github.com/paritytech/polkadot/issues/5898).
+layer](https://github.com/pezkuwichain/kurdistan-sdk/issues/162).
 
 For nodes that have been offline for a while, the same argument as for session
 changes holds, but matters even less: We assume 2/3 of nodes to be online, so