feat: Ruff formating and pre-commit ci for the codebase (#2082)

Signed-off-by: Manish Dait <daitmanish88@gmail.com>

Author: manishdait

.coderabbit.yaml

@@ -8,4 +8,4 @@ NETWORK=<NETWORK> #eg testnet/local/previewnet/mainnet, default to testnet or lo
 # TOKEN_ID=<TOKEN_ID>  #optional
 # TOKEN_NAME=<TOKEN_NAME>  #optional
 # TOKEN_SYMBOL=<TOKEN_SYMBOL>  #optional
-# TOPIC_ID=<TOPIC_ID>  #optional
+# TOPIC_ID=<TOPIC_ID>  #optional

.env.example

@@ -48,7 +48,7 @@
 
 # Documentation & legal
 /README.md                                     @hiero-ledger/hiero-sdk-python-maintainers
-/LICENSE                                       @hiero-ledger/hiero-sdk-python-maintainers @hiero-ledger/github-maintainers @hiero-ledger/tsc 
+/LICENSE                                       @hiero-ledger/hiero-sdk-python-maintainers @hiero-ledger/github-maintainers @hiero-ledger/tsc
 
 # Git ignore definitions
 **/.gitignore                                  @hiero-ledger/hiero-sdk-python-maintainers @hiero-ledger/github-maintainers

.github/CODEOWNERS

@@ -24,7 +24,7 @@ body:
         > This issue is not yet a confirmed Good First Issue.
         > It is being evaluated for suitability and may require
         > clarification or refinement before it is ready to be picked up.
-        > 
+        >
         > **Please wait for maintainer confirmation before asking to be assigned.**
     validations:
       required: false
@@ -100,13 +100,13 @@ body:
         > [!IMPORTANT]
         > **This issue does not require prior domain knowledge.**
         >
-        > - No Hiero or Hedera experience needed  
-        > - No distributed ledger background required  
+        > - No Hiero or Hedera experience needed
+        > - No distributed ledger background required
         > - **Beginner Programming is sufficient**
 
         > [!NOTE]
-        > ⏱️ **Typical time to complete:** ~1 Day / ~4 hours (including set-up)  
-        > 🧩 **Difficulty:** Small, well-contained change  
+        > ⏱️ **Typical time to complete:** ~1 Day / ~4 hours (including set-up)
+        > 🧩 **Difficulty:** Small, well-contained change
         > 🎓 **Best for:** New contributors
 
         🤖 AI Usage Policy
@@ -218,15 +218,15 @@ body:
         Once tests pass, a team member will check if your PR follows the workflow.
 
         **✅ 3. Team review**
-        Once your tests pass and the workflow is followed, a team member will review the implementation. 
+        Once your tests pass and the workflow is followed, a team member will review the implementation.
         You may be asked to make changes or your PR may be approved.
         Approved PRs are usually merged within **one day**.
 
         **🔄 Merge conflicts (sometimes)**
         Conflicts can happen and are normal as the SDK updates. Resolve using this [Guide](https://github.com/hiero-ledger/sdk-collaboration-hub/blob/main/guides/issue-progression/for-developers/merge_conflicts.md)
 
         > [!TIP]
-        > **Follow the workflow and double check your work** 
+        > **Follow the workflow and double check your work**
         > This is the best way to ensure a fast review and merge process.
         ---
 

.github/ISSUE_TEMPLATE/00-good-first-issue-candidate.yml

@@ -87,13 +87,13 @@ body:
         > [!IMPORTANT]
         > **This issue does not require prior domain knowledge.**
         >
-        > - No Hiero or Hedera experience needed  
-        > - No distributed ledger background required  
+        > - No Hiero or Hedera experience needed
+        > - No distributed ledger background required
         > - **Beginner Programming is sufficient**
 
         > [!NOTE]
-        > ⏱️ **Typical time to complete:** ~1 Day / ~4 hours (including set-up)  
-        > 🧩 **Difficulty:** Small, well-contained change  
+        > ⏱️ **Typical time to complete:** ~1 Day / ~4 hours (including set-up)
+        > 🧩 **Difficulty:** Small, well-contained change
         > 🎓 **Best for:** New contributors
 
         🤖 AI Usage Policy
@@ -205,15 +205,15 @@ body:
         Once tests pass, a team member will check if your PR follows the workflow.
 
         **✅ 3. Team review**
-        Once your tests pass and the workflow is followed, a team member will review the implementation. 
+        Once your tests pass and the workflow is followed, a team member will review the implementation.
         You may be asked to make changes or your PR may be approved.
         Approved PRs are usually merged within **one day**.
 
         **🔄 Merge conflicts (sometimes)**
         Conflicts can happen and are normal as the SDK updates. Resolve using this [Guide](https://github.com/hiero-ledger/sdk-collaboration-hub/blob/main/guides/issue-progression/for-developers/merge_conflicts.md)
 
         > [!TIP]
-        > **Follow the workflow and double check your work** 
+        > **Follow the workflow and double check your work**
         > This is the best way to ensure a fast review and merge process.
         ---
 

.github/ISSUE_TEMPLATE/01-good-first-issue.yml

@@ -38,10 +38,10 @@ body:
     attributes:
       label: 🐞 Problem Description
       description: |
-        Describe the issue so it is easy for a beginner contributor to understand what needs to be done and why. 
+        Describe the issue so it is easy for a beginner contributor to understand what needs to be done and why.
         Include which file(s) to look at, what the current behaviour is, and what the desired behaviour is.
       value: |
-        <!-- Describe the issue here -->  
+        <!-- Describe the issue here -->
 
         <!-- Identify which files to look at and patterns to recognise -->
 
@@ -137,7 +137,7 @@ body:
     attributes:
       label: 🧪 Testing Requirements
       description: |
-        Edit this section to set clear expectations for testing. 
+        Edit this section to set clear expectations for testing.
         What types of tests should they write? How should they run them? What should they link in their PR as evidence?
       value: |
         > [!IMPORTANT]

.github/ISSUE_TEMPLATE/02-beginner-issue.yml

@@ -95,7 +95,7 @@ body:
       description: |
         Adapt as needed. Technical areas this issue touches to help developers self-select based on expertise.
       value: |
-        <!-- Edit Technical Domains If needed -->      
+        <!-- Edit Technical Domains If needed -->
 
         - [ ] **Intermediate to Advanced Programming** (Object oriented design, inheritance, complex type systems)
         - [ ] **File Specific Knowledge** (request → serialization → execution → response mapping)
@@ -140,7 +140,7 @@ body:
     attributes:
       label: 🧪 Testing Requirements
       description: |
-        Edit this section to set clear expectations for testing. 
+        Edit this section to set clear expectations for testing.
         What types of tests should they write? How should they run them? What should they link in their PR as evidence?
       value: |
         How you test depends on the type of change.

.github/ISSUE_TEMPLATE/03-intermediate-issue.yml

@@ -36,7 +36,7 @@ body:
       description: |
         Clearly articulate the problem and its impact. The solution may be unclear or require significant research.
       value: |
-        <!-- Describe the issue here -->      
+        <!-- Describe the issue here -->
     validations:
       required: true
 
@@ -52,7 +52,7 @@ body:
         - Clarify what is unknown or uncertain about the implementation
         - Highlight any key risks or complexities
       value: |
-        <!-- Describe the implementation notes -->      
+        <!-- Describe the implementation notes -->
     validations:
       required: true
 
@@ -112,8 +112,8 @@ body:
         Advanced PRs must be **"safe, maintainable, architecturally sound, and production-ready."**
 
         1. **Architectural Fit:** The solution must fit naturally into the existing SDK abstractions.
-        2. **Security & Correctness:** Evaluate all logic for injection risks, state corruption, or thread-safety issues. 
-        3. **Maintainability:** Code must be short and clear enough for any other maintainer to debug without your assistance. 
+        2. **Security & Correctness:** Evaluate all logic for injection risks, state corruption, or thread-safety issues.
+        3. **Maintainability:** Code must be short and clear enough for any other maintainer to debug without your assistance.
         4. **Backward Compatibility:** Public API signatures must be preserved. If a breaking change is required, it must be explicitly managed through a deprecation cycle.
         5. **Comprehensive Testing:** Must include unit and integration tests covering all new logic paths, edge cases, and failure modes. AI generated tests based on AI generated code is grounds for immediate rejection.
 

.github/ISSUE_TEMPLATE/04-advanced-issue.yml

@@ -68,4 +68,4 @@ body:
         - Linux
         - macOS
         - Windows
-        - Other
+        - Other

.github/ISSUE_TEMPLATE/bug.yml

@@ -31,4 +31,4 @@ Identify any modifications to the public-facing interface.
 ---
 
 ### 🏁 Summary Verdict
-Provide a 1-sentence summary of the "Safety" of this release candidate.
+Provide a 1-sentence summary of the "Safety" of this release candidate.