## Group paired indices explicitly when entry order interleaves them

What happened: T557 enumerated (m,n) by (mn,m,n), but the API export returned
Numbers nested first by m. This made the initial readback checker reject the
shape, and the nested grouping could put the full m=1 slice ahead of (2,1).
All 207 values themselves matched the generator. Setting
`Display properties: group parameters: [[m, n]]` and ordering the records by
(mn,m,n) preserved the intended global order. The checker now reads all supported
API entry forms through the existing numberdb client parser.

What the skill says now: entries appear in document order, and enumeration
should put the small cases first. It does not explain how default multi-parameter
grouping can undo a globally interleaved enumeration on export or display.

What it should say: for an ordering that interleaves different values of the
first parameter, group the parameters in a single display level and check the
order after reading the table back. Do not assume Numbers is a flat list;
API documents may be nested or grouped even when entries were submitted flat.

Evidence: T557; build-work/readback.log records 207/207 matches followed by
'Expected flat entries'; readback-final.log records 207 successful independent
checks and an exact ordered match after grouping. No polynomial was changed.
This is a portable client/API lesson, not a deployment issue. Proposed only;
the canonical skill and repository source were not edited.