chore: enable isort ruff rule and apply fixes

[Aswinr24]

Description

This PR enables additional Ruff linting rules and applies fixes to the codebase as suggested by Ruff. The changes include:

Enabling I (isort) rule in pyproject.toml.

fixes issues raised by ruff linter which included:

• I001: Ensure consistent and standardized sorting of top-level imports across files.

Related to #4925

Type of change

Please add a line in the relevant section of CHANGELOG.md to document the change (include PR #)

• New feature (non-breaking change which adds functionality)
• Optimization (back-end change that speeds up the code)
• Bug fix (non-breaking change which fixes an issue)

Important checks:

Please confirm the following before marking the PR as ready for review:

• No style issues: nox -s pre-commit
• All tests pass: nox -s tests
• The documentation builds: nox -s doctests
• Code is commented for hard-to-understand areas
• Tests added that prove fix is effective or that feature works

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.57%. Comparing base (a1f2134) to head (2efc083).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #5003      +/-   ##
===========================================
- Coverage    98.57%   98.57%   -0.01%     
===========================================
  Files          304      304              
  Lines        23661    23655       -6     
===========================================
- Hits         23325    23319       -6     
  Misses         336      336              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[agriyakhetarpal]

Hi @Aswinr24, could you please resolve the merge conflicts here? Thanks!

Also, as this is a linting-only change and performs no changes in functionality, we should leave the commit hash for the changes in the .git-blame-ignore-revs file.

What can be done here is:

• rebase the PR on top of the develop branch
• resolve all the conflicts that are currently present and get pre-commit checks to pass
• squash all the changes into one commit, say, commit X
• in a second commit Y, add the SHA for commit X in .git-blame-ignore-revs

Here is an article that should serve as helpful reading: https://graphite.dev/guides/git-blame-ignore-revs

We can then merge the PR (not squash-merge, but a regular merge).

[kratman]

Hi @Aswinr24, could you please resolve the merge conflicts here? Thanks!

Also, as this is a linting-only change and performs no changes in functionality, we should leave the commit hash for the changes in the .git-blame-ignore-revs file.

What can be done here is:

• rebase the PR on top of the develop branch
• resolve all the conflicts that are currently present and get pre-commit checks to pass
• squash all the changes into one commit, say, commit X
• in a second commit Y, add the SHA for commit X in .git-blame-ignore-revs

Here is an article that should serve as helpful reading: https://graphite.dev/guides/git-blame-ignore-revs

We can then merge the PR (not squash-merge, but a regular merge).

Since this is just changing the order of the import statements, we can probably skip the ignore-revs part

[agriyakhetarpal]

Hi @Aswinr24, could you please resolve the merge conflicts here? Thanks!
Also, as this is a linting-only change and performs no changes in functionality, we should leave the commit hash for the changes in the .git-blame-ignore-revs file.
What can be done here is:

• rebase the PR on top of the develop branch
• resolve all the conflicts that are currently present and get pre-commit checks to pass
• squash all the changes into one commit, say, commit X
• in a second commit Y, add the SHA for commit X in .git-blame-ignore-revs

Here is an article that should serve as helpful reading: graphite.dev/guides/git-blame-ignore-revs
We can then merge the PR (not squash-merge, but a regular merge).

Since this is just changing the order of the import statements, we can probably skip the ignore-revs part

I'm not sure I follow – changing the order of the import statements is a style-only change and is not useful at all in the git blame, i.e., it rather provides a reason to add it to the ignore-revs file instead of not doing so?

[Aswinr24]

Hi @Aswinr24, could you please resolve the merge conflicts here? Thanks!

Also, as this is a linting-only change and performs no changes in functionality, we should leave the commit hash for the changes in the .git-blame-ignore-revs file.

What can be done here is:

• rebase the PR on top of the develop branch
• resolve all the conflicts that are currently present and get pre-commit checks to pass
• squash all the changes into one commit, say, commit X
• in a second commit Y, add the SHA for commit X in .git-blame-ignore-revs

Here is an article that should serve as helpful reading: https://graphite.dev/guides/git-blame-ignore-revs

We can then merge the PR (not squash-merge, but a regular merge).

Thanks! Yes, will resolve the merge conflicts and do the necessary changes.

[kratman]

This file was deleted in #4996

Can you remove this version of it and re-do the rebase

[kratman]

Sometimes with formatting changes like these, the best approach is to hard reset to the base branch, then re-apply the pre-commit. It is safer than merging and squashing since that modifies history

[Aswinr24]

Sure will fix this

[kratman]

A file was mistakenly re-added. This was caught by the docs tests