P2: Rework the issues table around activity

The issues list is the page people scan first, and its columns still describe a project nobody browses by author or by age. Rework the table so it answers “what changed, and who is on it” at a glance.

Why

• An issue list is read for activity, not for creation order. A list sorted by when an issue was opened buries the one somebody just answered.
• The author’s own column spends a whole column on a name that rarely changes the reader’s decision; assignees are the people who own the work.
• Labels are the fastest way to tell a bug from a tracking item, and they are squeezed into the title’s metadata line where they compete with the number.

Scope

• Assignees render like authors do, not as label chips. They link to the person’s profile the same way the author does.
• The Age column becomes Updated: the last time the issue was edited, commented on, or otherwise changed.
• The creation time and the author move under the title, where the labels are shown today.
• Labels get a column of their own.
• The list sorts by Updated, newest first, by default. Open issues still come before closed ones when both are shown.

Acceptance criteria

• /r/<repo>/issues shows the columns Status, Issue, Labels, Assignees, Replies, Updated.
• Updated reflects a new comment and an edit of the title, description, state, or labels, not just the creation date.
• The default order puts the most recently updated issue first within each state group.
• The index’s incremental refresh and full rebuild agree on Updated, and the existing index tests still pass.