A reviewer discovered a merge request only through their dashboard review queue,
which is narrowed by involvement — repositories they own, are granted on, or
reach through an org or team. Nothing was ever pushed to a particular person, so
a collaborator who had not yet commented got nothing for the whole life of a
merge request. mr ready made it worst: marking a draft ready is the moment the
author asks, and there was nobody to address it to.
mr review request <owner/name> <n> [--add <user>]... [--remove <user>]...,
matching issue assign's shape, recorded in mr_review_requests (migration
0042, modelled on issue_assignees including its per-user index).
The review queue gains a second half that is not narrowed by involvement, for
the reason already written on AssignedIssues: a direct request for someone's
attention is not the same as involvement. Both halves keep the rules that
matter — the merge request leaves the queue once that person reviews the current
head, returns when a new head is pushed, and never appears in its own author's
queue. The new half drives from the request table rather than testing EXISTS
against every merge request, and dashboardplan_test.go covers its index.
mr ready now notifies whoever was asked.
Review found an event kind that lied to subscribers: mr.review_requested was
recorded but absent from EventKinds, so webhook create --events mr.review_requested was refused for an event the forge emits. The guard test
that exists to catch exactly that could not see it — its regex was [a-z.]+ and
this is the first kind with an underscore, so the kind was invisible to both
directions of a bidirectional check. Both the kind and the character class are
fixed; the second is the part that stops the next one slipping through.
Closes #145