[HnR-Autograder:6] Dashboard columns

[gmorador-tribu]

The students table of a Hide & Reveal assignment repeats its metrics once per
phase, each under the header of its phase. When the assignment is also
auto-graded every phase gets its own grade plus a final grade; only the final
grade is synced, because the LMS gradebook has one grade per assignment.

Four commits, in order:

1. GroupedActivityTable — the table with grouped column headers, assembled
   out of the frontend-shared primitives because DataTable cannot render a
   second header row. OrderableActivityTable becomes the facade which picks
   between the two, driven by the data: a column set which declares no group
   renders exactly as it does today, through DataTable.
2. The checkpoint variants — plus a change to how the registry resolves one.
   Predicates which had to exclude each other's capabilities meant adding a
   variant edited the variants which came before it. Now a variant declares the
   capabilities it handles and the registry picks the one which declares exactly
   that set, so nothing has to be excluded and two variants can only claim the
   same assignment by declaring the same set.
3. checkpoint_enabled in the dashboard API — emitted for every assignment
   rather than only when true, unlike auto_grading_config: the frontend reads
   it to choose between two table shapes, and an absent key would b
   indistinguishable from a backend which does not report it yet.
4. Ordering the instructor email digest recipients — unrelated,
   purpose. That query had no ORDER BY, and adding the two dashboard API tests
   in this PR reshuffled the xdist distribution (the unit tests all share one
   database), which turned a test that had been passing by luck red
   this PR's pipeline fails. Happy to move it to its own PR off main if you'd
   rather keep this one focused.

Two things to read before reviewing:

• None of this is reachable yet. The phase_metrics contract i
  the PoC in [HnR-Autograder:4] Annotations api #7445 and no backend emits it, so the checkpoint varia
  fall through to the "no phase reported" branch and only the tests exercise that
  code. That is deliberate.
• **A real Hide & Reveal assignment looks exactly as it does today.
  student reports gets no columns, and while none is reported the table is the
  one the assignment would display without checkpoints. That is also the product
  rule — a section which is not defined gets no column — and it is
  this from rendering a grid of empty cells against the current backend.

Deliberately out of scope: column widths and the layout for mor
checkpoint (two checkpoints means twelve columns, and the headers stop fitting),
and the phase labels for more than one checkpoint, which cannot be derived yet
because the API reports a phase's position and never how many the a

[Elimpizza]

This same field is added in PR #7445 (checkpoint_enabled on APIAssignment + this constructor + the same four full-dict assertions in assignment_test.py), so one of the two PRs has to drop it or we get a guaranteed conflict and two different comments explaining one field.
I'd suggest PR 7445 keeps it: it needs due_date on the same TypedDict anyway, so the two land together there. Then this PR drops js_config_types.py, views/dashboard/api/assignment.py and the test changes, and picks them up on rebase. Happy to do it the other way round if you'd rather