P2: Say what each change is waiting for in the list

The changes list still reads like a table of records: a state chip that says only open or merged, an approval fraction, the same author column on every row, and an age measured from opening. None of that answers the question people open the page with: what is this change waiting for?

Why

• A change spends most of its life in states the list cannot show: held for CI approval, running checks, failed checks, waiting for a reviewer, conflicting with the base.
• The state chip is the least useful fact on the row. “Open” covers everything from “nobody has looked at it” to “approved and green”.
• The list is read for what moved, not for what was opened first.

Scope

• One Status column that says where the change is, in one short label.
• The labels cover: waiting on CI approval, waiting on CI jobs, CI failed, waiting for review, merge conflict, ready to merge, merged, closed.
• A tooltip explains each label.
• Author and opening time move under the title, like the issue list.
• An Updated column showing the last edit, comment or approval, and the list sorts by it.

Acceptance criteria

• /r/<repo>/requests has the columns Status, Change, Base ← Head, Updated.
• A change with fewer approvals than required reads “Waiting for review”; one with a held contributor tip reads “Waiting on CI approval”; queued or running checks read “Waiting on CI jobs”; a failed run reads “CI failed”.
• A merged change reads “Merged”; a closed one reads “Closed”.
• The default order puts the most recently updated change first within each state group.
• The index’s incremental refresh and full rebuild agree on the update time.