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.

bizinikiwi/primitives/statement-store/README.md

@@ -0,0 +1,56 @@
+# Statement store
+
+Statement store is an off-chain data-store for signed statements accessible via RPC and OCW.
+
+Nodes hold a number of statements with a proof of authenticity owing to an account ID. OCWs can place items in the
+data-store (with valid signatures) for any accounts whose keys they control. Users can also submit pre-signed statements
+via RPC. Statements can also be submitted from on-chain logic through an on-chain event.
+
+A new system event `NewStatement` is added to the runtime. This event allows any account on-chain to declare that they
+want to make a statement for the store. Within the node store and for broadcasting, the statement would be accompanied
+with the hash of the block and index of the event within it, essentially taking the place of a real signature.
+
+Statements comprise an optional proof of authenticity (e.g. a signature) and a number of fields. For statements without
+a proof, nodes would gossip statements randomly with a rate-limiter to minimise the chance of being overrun by a
+misbehaving node. These will generally be disregarded by nodes unless they are gossiped by several different peers or if
+a peer pays for it somehow (e.g. gossiping something valuable).
+
+Each field is effectively a key/value pair. Fields must be sorted and the same field type may not be repeated. Depending
+on which keys are present, clients may index the message for ease of retrieval.
+
+Formally, `Statement` is equivalent to the type `Vec<Field>` and `Field` is the SCALE-encoded enumeration:
+- 0: `AuthenticityProof(Proof)`: The signature of the message. For cryptography where the public key cannot be derived
+  from the signature together with the message data, then this will also include the signer's public key. The message
+  data is all fields of the messages fields except the signature concatenated together *without the length prefix that a
+  `Vec` would usually imply*. This is so that the signature can be derived without needing to re-encode the statement.
+- 1: `DecryptionKey([u8; 32])`: The decryption key identifier which should be used to decrypt the statement's data. In
+  the absence of this field `Data` should be treated as not encrypted.
+- 2: `Priority(u32)`: Priority specifier. Higher priority statements should be kept around at the cost of lower priority
+  statements if multiple statements from the same sender are competing for persistence or transport. Nodes should
+  disregard when considering unsigned statements.
+- 3: `Channel([u8; 32])`: The channel identifier. Only one message of a given channel should be retained at once (the
+  one of highest priority). Nodes should disregard when considering unsigned statements.
+- 4: `Topic1([u8; 32]))`: First topic identifier.
+- 5: `Topic2([u8; 32]))`: Second topic identifier.
+- 6: `Topic3([u8; 32]))`: Third topic identifier.
+- 7: `Topic4([u8; 32]))`: Fourth topic identifier.
+- 8: `Data(Vec<u8>)`: General data segment. No special meaning.
+
+`Proof` is defined as the SCALE-encoded enumeration:
+- 0: `Sr25519 { signature: [u8; 64], signer: [u8; 32] }`
+- 1: `Ed25519 { signature: [u8; 64], signer: [u8; 32] )`
+- 2: `Secp256k1Ecdsa { signature: [u8; 65], signer: [u8; 33] )`
+- 3: `OnChain { who: [u8; 32], block_hash: [u8; 32], event_index: u64 }`
+
+## Potential uses
+
+Potential use-cases are various and include:
+- ring-signature aggregation;
+- messaging;
+- state-channels;
+- deferral of the initial "advertising" phase of multi-party transactions;
+- publication of preimage data whose hash is referenced on-chain;
+- effective transferal of fee payment to a second-party.
+
+
+License: Apache-2.0