Stabilise django-extra (S610) for release 0.5

[AlexWaygood]

The motivation for this rule is solid; it's been in preview for a long time; the implementation and tests seem sound; there are no open issues regarding it, and as far as I can tell there never have been any.

The only issue I see is that the docs don't really describe the rule accurately right now; I fix that in this PR.

[github-actions]

ruff-ecosystem results

Linter (stable)

ℹ️ ecosystem check detected linter changes. (+22 -0 violations, +0 -0 fixes in 1 projects; 49 projects unchanged)

zulip/zulip (+22 -0 violations, +0 -0 fixes)

ruff check --no-cache --exit-zero --ignore RUF9 --output-format concise --no-preview --select ALL

+ zerver/actions/message_flags.py:117:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/actions/message_flags.py:169:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/actions/message_flags.py:241:15: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/actions/message_flags.py:48:15: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/actions/message_flags.py:65:23: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/lib/message.py:568:15: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/lib/message.py:609:36: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/lib/push_notifications.py:1086:15: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/lib/query_helpers.py:26:24: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/lib/users.py:227:89: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/models/streams.py:268:47: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_flags.py:361:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_flags.py:394:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_flags.py:790:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_flags.py:893:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_flags.py:903:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_move_topic.py:1552:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_move_topic.py:1559:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_move_topic.py:1624:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_move_topic.py:1631:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/views/read_receipts.py:81:15: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/worker/deferred_work.py:90:93: S610 Use of Django `extra` can lead to SQL injection vulnerabilities

Changes by rule (1 rules affected)

code	total	+ violation	- violation	+ fix	- fix
S610	22	22	0	0	0

Linter (preview)

✅ ecosystem check detected no linter changes.

[AlexWaygood]

The ecosystem check reports that there would be 22 new S610 violations as a result of this stabilisation, but it only links to E721 violations (and I haven't modified the logic for E721 as part of this PR, so I think those are all spurious). So I haven't been able to check whether the 22 new S610 violations are true positives or false positives.

[AlexWaygood]

Okay, rebasing fixed the ecosystem report. All 22 hits are in one project, zulip. I skimmed through them -- they all seem like exactly the kind of thing the check is designed to flag, and exactly the kind of thing a security-related lint rule should be flagging. So I think this is good to go.