feat: worst-wins reconciliation for shared-token review types

When multiple review types share a Gitea bot account, Gitea uses the
latest review to determine the user's approval state. This creates a
race: if security finds issues but code-quality finishes last with
APPROVE, the PR appears approved.

Now before posting, each job checks if any sibling review from the same
user has REQUEST_CHANGES. If so and we would post APPROVE, we downgrade
to COMMENT instead — the review is still visible but won't override
the blocking state.

Documented in README under "Shared Token: Worst-Wins."

README.md

@@ -205,6 +205,14 @@ On the next run, it finds and deletes any review containing its own sentinel (ex
 
 If `reviewer-name` is empty, cleanup is skipped (reviews stack like before).
 
+### Shared Token: Worst-Wins Behavior
+
+When multiple review types share the same Gitea bot account (e.g. code-quality and security), Gitea determines the user's approval state from their **most recent review**. This creates a race condition: if security finds issues (REQUEST_CHANGES) but code-quality finishes last (APPROVE), the PR appears approved.
+
+review-bot handles this automatically with **worst-wins reconciliation**: before posting, each job checks whether any sibling review from the same user already has REQUEST_CHANGES. If so and this job would post APPROVE, it posts as REQUEST_CHANGES instead — maintaining the block. This ensures the PR stays blocked until all checks pass, regardless of execution order.
+
+**If you need independent approval/block per review type**, use separate Gitea bot accounts with their own tokens.
+
 ## Custom Review Prompts
 
 Use `system-prompt-file` to specialize the review focus. The file contents are appended to the base system prompt as "Additional Review Instructions."