chore: add ruff-extra-rules linter/formatter

[alessio-locatelli]

Background: During code review, I've noticed that I repeat the same feedback for both coding agents and human developers. Some of these rules are either not yet implemented in linters or still under development, so I decided to fill this gap.

I'm flexible on the outcome:

• This is rejected with a reason
• This is kept as an addition to ruff

---

If there will be a green light on this, I would like to submit an equivalent PR for https://github.com/requests-cache/requests-cache/

[JWCook]

Interesting! So far I've just looked over your docs and didn't dive into the code, but ruff-extra-rules looks carefully thought out. I don't think I've seen semantic analysis in a linter before (redundant-assignment/TR5 rule). TR3 looks useful; that one has bitten me before.

For rule TR7, how does it identify which line is the relevant expression that a comment belongs to, if there are multiple expressions within the bracket?

No objections here; go ahead and merge this if you'd like.

[alessio-locatelli]

Thanks for taking a look!

Background on TR7: While working on several large codebases, I observed that enforcing the configured line-length limit caused Black and Ruff to automatically reformat inline comments associated with specific parameters by relocating them to the closing bracket. This significantly reduced code readability and necessitated manual inspection via grep to identify and correct misplaced comments. Approximately 90% of these instances involved single-argument statements that could have been automatically resolved had a dedicated rule been available at the time.

On TR7: it's purely positional, no attempt to resolve which argument the comment describes.

1. It only fires when the closing-bracket line contains nothing but closing brackets — is_bracket_only_line rejects any line where an expression shares the line with the bracket (so foo(a, b) # comment is untouched; only the bracket-on-its-own-line shape is in scope).
2. When it fires, the fix always attaches the comment to whichever line is physically immediately above the bracket-only line — prev_line_idx = bracket_line_idx - 1. With multiple expressions inside the bracket, that's always the last one listed.

The preceding-placement test case shows this with two arguments — the comment lands as a preceding comment on argument_two, the line adjacent to the bracket, regardless of which argument it was originally meant to describe.

Yes, TR7 with --fix enabled may be flaky in rare cases, and I'm aware it can move the comment from one wrong position to another for multi-argument statements. --fix is opt-in on the tool itself, and even where a project turns it on by default like this one does, the developer still reviews the diff before committing it.

Glad TR3 and TR5 landed well — I'll go ahead and merge this, thanks for the review.