feat(apidocs): Lint request parameters read without a serializer

[azulus]

Reports a parameter read straight off request.GET or request.data instead of through a serializer.

Such a parameter is invisible twice over. The schema has nothing to generate from, so no client can send it, and the value arrives as an unchecked string, so a misspelled key fails in production rather than in review. Reading through a serializer named in @extend_schema fixes both at once, because drf-spectacular derives the documented parameters from the same field objects the handler validates with. Ten public endpoints already work this way; this rule reports everyone else.

Three diagnostics share the rule, separating cases that differ in how they get fixed: a literal key read straight off the input, a key computed at runtime that no schema could ever document, and the whole dict handed to a callable so that what it reads is unknowable from the call site. Counting or iterating the dict is not a hand-off, building a serializer from it is the target rather than a violation, and reads through validated_data are accepted.

A read has to hang off request or self.request to count. serializer.data and response.data are outputs a handler builds, not parameters a client sent, and subscript writes such as request.data["title"] = default are not reads either.

The rule is absent from ENFORCED, so nothing gates. The backlog is 197 raw reads, two computed keys, and 17 hand-offs.

Follows #123919, which added the ratchet this rule hangs off.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8da245c. Configure here.}