Development (#172)

* docs: Add CLAUDE_RULES.md with strict rebrand protection rules

- Define immutable rebrand rules that cannot be violated
- Prohibit reverting rebrand for cargo check convenience
- Establish checkpoint and audit trail requirements
- Document correct error handling approach

* refactor: Complete kurdistan-sdk to pezkuwi-sdk rebrand

- Update README.md with pezkuwi-sdk branding
- Replace all kurdistan-sdk URL references with pezkuwi-sdk
- Replace kurdistan-tech with pezkuwichain in workflows
- Update email domains from @kurdistan-tech.io to @pezkuwichain.io
- Rename tool references: kurdistan-tech-publish → pezkuwi-publish
- Update runner names: kurdistan-tech-* → pezkuwichain-*
- Update analytics/forum/matrix domains to pezkuwichain.io
- Keep 'Kurdistan Tech Institute' as organization name
- Keep tech@kurdistan.gov as official government contact

pezkuwi/roadmap/implementers-guide/src/node/availability/availability-distribution.md

@@ -65,13 +65,13 @@ Note however that, because not all validators in a group have to be actual backe
 the needed chunk. This in turn could lead to low throughput, as we have to wait for fetches to fail, before reaching a
 validator finally having our chunk. We do rank back validators not delivering our chunk, but as backers could vary from
 block to block on a perfectly legitimate basis, this is still not ideal. See issues
-[2509](https://github.com/pezkuwichain/kurdistan-sdk/issues/136) and
-[2512](https://github.com/pezkuwichain/kurdistan-sdk/issues/137) for more information.
+[2509](https://github.com/pezkuwichain/pezkuwi-sdk/issues/136) and
+[2512](https://github.com/pezkuwichain/pezkuwi-sdk/issues/137) for more information.
 
 The current implementation also only fetches chunks for occupied cores in blocks in active leaves. This means though, if
 active leaves skips a block or we are particularly slow in fetching our chunk, we might not fetch our chunk if
 availability reached 2/3 fast enough (slot becomes free). This is not desirable as we would like as many validators as
-possible to have their chunk. See this [issue](https://github.com/pezkuwichain/kurdistan-sdk/issues/138) for more details.
+possible to have their chunk. See this [issue](https://github.com/pezkuwichain/pezkuwi-sdk/issues/138) for more details.
 
 
 ### Serving

pezkuwi/roadmap/implementers-guide/src/node/collators/collator-protocol.md

@@ -19,7 +19,7 @@ not being wasted by attackers. Communicating across this trust-boundary is the m
 Validation of candidates is a heavy task, and furthermore, the [`PoV`][PoV] itself is a large piece of data.
 Empirically, `PoV`s are on the order of 10MB.
 
-> TODO: note the incremental validation function Ximin proposes at https://github.com/pezkuwichain/kurdistan-sdk/issues/130
+> TODO: note the incremental validation function Ximin proposes at https://github.com/pezkuwichain/pezkuwi-sdk/issues/130
 
 As this network protocol serves as a bridge between collators and validators, it communicates primarily with one
 subsystem on behalf of each. As a collator, this will receive messages from the [`CollationGeneration`][CG] subsystem.

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/pezkuwichain/kurdistan-sdk/issues/144) ticket.
+[this](https://github.com/pezkuwichain/pezkuwi-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/pezkuwichain/kurdistan-sdk/issues/161).
+issue](https://github.com/pezkuwichain/pezkuwi-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/pezkuwichain/kurdistan-sdk/issues/162) in case of high
+limit inclusion for example (as suggested [here](https://github.com/pezkuwichain/pezkuwi-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,7 +202,7 @@ 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
-Bizinikiwi level, but [are not](https://github.com/pezkuwichain/kurdistan-sdk/issues/30)
+Bizinikiwi level, but [are not](https://github.com/pezkuwichain/pezkuwi-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/pezkuwichain/kurdistan-sdk/issues/162).
+layer](https://github.com/pezkuwichain/pezkuwi-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

pezkuwi/roadmap/implementers-guide/src/node/utility/gossip-support.md

@@ -11,7 +11,7 @@ limits the amount of messages sent and received to be an order of sqrt of the
 validators. Our neighbors in this graph will be forwarded to the network bridge
 with the `NetworkBridgeMessage::NewGossipTopology` message.
 
-See https://github.com/pezkuwichain/kurdistan-sdk/issues/141 for more details.
+See https://github.com/pezkuwichain/pezkuwi-sdk/issues/141 for more details.
 
 The gossip topology is used by teyrchain distribution subsystems,
 such as Bitfield Distribution, (small) Statement Distribution and

pezkuwi/roadmap/implementers-guide/src/protocol-validator-disabling.md

@@ -430,7 +430,7 @@ Implementation of the above design covers a few additional areas that allow for
     > This would guarantee determinism as different nodes can see different leaves, but this approach was leaving too
     > wide of a window because of Async-Backing. Relay Parent could have been significantly in the past and it would
     > give a lot of time for past session disputes to be spammed.
-1. Do not block finality for "disabled" disputes [#3358](https://github.com/pezkuwichain/kurdistan-sdk/issues/114)
+1. Do not block finality for "disabled" disputes [#3358](https://github.com/pezkuwichain/pezkuwi-sdk/issues/114)
     - Emergency fix to not block finality for disputes initiated only by disabled validators
 1. Re-enable small offender when approaching BZT (**Runtime**) #TODO
     - When BZT limit is reached and there are more offenders to be disabled re-enable the smallest offenders to disable

pezkuwi/roadmap/implementers-guide/src/runtime/session_info.md

@@ -14,7 +14,7 @@ struct SessionInfo {
     ///
     /// NOTE: There might be more authorities in the current session, than `validators` participating
     /// in teyrchain consensus. See
-    /// [`max_validators`](https://github.com/pezkuwichain/kurdistan-sdk/blob/main/pezkuwi/runtime/teyrchains/src/configuration.rs#L148)..
+    /// [`max_validators`](https://github.com/pezkuwichain/pezkuwi-sdk/blob/main/pezkuwi/runtime/teyrchains/src/configuration.rs#L148)..
     ///
     /// `SessionInfo::validators` will be limited to `max_validators` when set.
     validators: Vec<ValidatorId>,
@@ -23,14 +23,14 @@ struct SessionInfo {
     /// NOTE: The first `validators.len()` entries will match the corresponding validators in
     /// `validators`, afterwards any remaining authorities can be found. This is any authorities not
     /// participating in teyrchain consensus - see
-    /// [`max_validators`](https://github.com/pezkuwichain/kurdistan-sdk/blob/main/pezkuwi/runtime/teyrchains/src/configuration.rs#L148).
+    /// [`max_validators`](https://github.com/pezkuwichain/pezkuwi-sdk/blob/main/pezkuwi/runtime/teyrchains/src/configuration.rs#L148).
     #[cfg_attr(feature = "std", ignore_malloc_size_of = "outside type")]
     discovery_keys: Vec<AuthorityDiscoveryId>,
     /// The assignment keys for validators.
     ///
     /// NOTE: There might be more authorities in the current session, than validators participating
     /// in teyrchain consensus. See
-    /// [`max_validators`](https://github.com/pezkuwichain/kurdistan-sdk/blob/main/pezkuwi/runtime/teyrchains/src/configuration.rs#L148)..
+    /// [`max_validators`](https://github.com/pezkuwichain/pezkuwi-sdk/blob/main/pezkuwi/runtime/teyrchains/src/configuration.rs#L148)..
     ///
     /// Therefore:
     /// ```ignore

pezkuwi/roadmap/implementers-guide/src/types/runtime.md

@@ -7,7 +7,7 @@ Types used within the runtime exclusively and pervasively.
 The internal-to-runtime configuration of the teyrchain host is kept in `struct HostConfiguration`. This is expected to
 be altered only by governance procedures or via migrations from the Pezkuwi-SDK codebase. The latest definition of
 `HostConfiguration` can be found in the project repo
-[here](https://github.com/pezkuwichain/kurdistan-sdk/blob/main/pezkuwi/runtime/teyrchains/src/configuration.rs). Each
+[here](https://github.com/pezkuwichain/pezkuwi-sdk/blob/main/pezkuwi/runtime/teyrchains/src/configuration.rs). Each
 parameter has got a doc comment so for any details please refer to the code.
 
 Some related parameters in `HostConfiguration` are grouped together so that they can be managed easily. These are:
@@ -20,7 +20,7 @@ Check the definitions of these structs for further details.
 
 ### Configuration migrations
 Modifying `HostConfiguration` requires a storage migration. These migrations are located in the
-[`migrations`](https://github.com/pezkuwichain/kurdistan-sdk/blob/main/pezkuwi/runtime/teyrchains/src/configuration.rs)
+[`migrations`](https://github.com/pezkuwichain/pezkuwi-sdk/blob/main/pezkuwi/runtime/teyrchains/src/configuration.rs)
 subfolder of Pezkuwi-SDK repo.
 
 ## ParaInherentData