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/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