prlinter: should create a status instead of a "request changes" review

### Describe the feature

The "request changes" review causes problems if there are checks that might take a while to know the answer to (for example, other runs).

For full safety we should "request changes" while the checks are still running, so the PR isn't accidentally merged before the check turns green.

But then a `merge-from-live → checks in progress → request changes → Mergify dequeue`, which is not what we want.

Instead, a `status` has 3 possible values: "good / bad / don't know yet", which we should use for this purpose.

The issue names prlinter but does not identify a file or test. Start by locating prlinter's handling of checks and pull-request reviews, then trace how the current "request changes" result affects Mergify dequeue behavior. Done means the checks-in-progress case uses a status with good, bad, or unknown semantics without producing the unwanted request-changes review.

Written by the indexing model from the issue text.