DataView follow-ups from #162: retry loader state, HasManyDataGrid selection keying, test robustness #164

Follow-up to #162 (fixes for #124, #145, #146). Four minor points from its last review round, deferred so the reviewed commit could be merged as is.

1. A retry after a failure reports failed for one render

When a load fails and the view is reloaded, the render that changes the request still reports loaderState === 'failed'; the next render reports initial. The DataViewLoaderState docs say failed means "the current query failed", which is not true on that render: the current query has not run yet.

• Where: HasManyDataGrid.tsx (error states) and, in shared code, packages/bindx-react/src/hooks/useEntityList.ts (the error branch of the list state).
• Fix: record the request key in the error state as well, and report failed only when it matches the current request; otherwise initial.
• Test: record the loader state on every render across a retry, not only after act() settles.

2. No regression test for HasManyDataGrid refetching on parent re-renders

#162 made the HasManyDataGrid data effect follow its request key instead of the setup.selection object, which is new on every parent render with inline children. Before, each parent re-render refetched the relation. No test pins this: putting setup.selection back into the effect's dependencies keeps the suite green.

• Test: count the relation get queries while the parent re-renders with unchanged inline children; expect none after the first load.

3. HasManyDataGrid writes the latest selection to a ref during render

selectionRef.current = setup.selection runs in render so the effect can read the selection without depending on its identity. It is safe in practice, but React's rules advise against writing refs during render, and the effect's dependency list omits a value it uses.

• Fix: keep one selection object per content key (the pattern in useEntityList, which swaps its selectionMeta only when the serialized query changes), list it in the dependencies and drop the ref. Do it together with 2.

4. The double-reload infinite-load test depends on mock timing

tests/react/dataview/infiniteLoad.test.tsx, "a reload during a reload keeps the list shown at the first one": the second reload has to land within the mock adapter's 10 ms delay. On a loaded machine the first reload can finish first, so the snapshot clears and the assertion fails even though the code is right.

• Fix: use a test adapter that holds responses until the test releases them.