DataPage renders an empty table when given defaultFilters (any value, including {})

[woksin]

What happens

A DataPage given the defaultFilters prop renders zero rows and shows its emptyMessage, while its own
paginator simultaneously reports the true row count ("1–20 of 24"). Removing the prop restores the rows.

defaultFilters?: DataTableFilterMeta is a declared, public member of DataPageProps
(dist/esm/DataPage/DataPage.d.ts), so this is a supported prop, not an accidental pass-through.

Evidence

Measured in a browser against @cratis/components 3.4.0 / primereact 11.1.0, on a clean dev server,
by single-variable bisect on one story.

Configuration	Rows rendered	Paginator
defaultFilters + clientFiltering	0 (emptytbody)	1–20 of 24
clientFiltering only	20	1–20 of 24
defaultFilters only	0 (emptytbody)	1–20 of 24

The prop's content is irrelevant — defaultFilters={{}} reproduces it, as does a single entry with a real
value. Column filter flags are irrelevant too: removing filter from every column still reproduces it.

Isolated to DataPage. Probed one layer at a time with throwaway stories, all against the same
QueryFor-derived snapshot query (so DataPage mounts DataTableForQuery internally in every row below):

• DataTableCore with defaultFilters={{}} → 3 of 3 rows. Also 3 of 3 under renderToStaticMarkup.
• DataTableForQuery with defaultFilters={{}} → 3 of 3 rows.
• DataPage with defaultFilters={{}} → 0 rows.

So the inner table and the query wrapper are both correct with the same prop, and something in DataPage's own
composition is not.

One candidate, offered as an observation and explicitly not as a proven mechanism. DataPage builds

const context = { ...props, selectedItem, onSelectionChanged: selectionChanged };

fresh on every render (dist/esm/DataPage/DataPage.js) and DataPage.Columns spreads that object into the
inner table (jsx(DataTableForQuery, { ...context, … })), so every inner-table prop changes identity on every
render. That is the visible structural difference between the working direct usage and the failing composed
one — it was not proven to be the cause.

Reproduction

A DataPage over any query, defaultFilters={{}}, no other change.

What it costs a consumer

For us today: zero. DataPage appears nowhere in our production code — only in one adoption fixture story,
where the prop has been removed with a comment. Our real tables use DataTableForObservableQuery, the
proven-good path, and keep their filter meta.

We are reporting it because a declared prop that silently empties the table is expensive for whoever hits it
next: the paginator keeps reporting the true count, so the page looks like a data problem rather than a prop
problem, and nothing in a type-check, lint or unit test flags it.

Suggested fix — the seam

Make DataPage honor defaultFilters the way DataTableForQuery and DataTableCore already do. If the prop
cannot be supported at the DataPage level, remove it from DataPageProps — a declared prop that empties the
table is worse than an absent one.

What is explicitly not being asked for

Not asking for any change to DataTableCore, DataTableForQuery or DataTableForObservableQuery — all three
behave correctly with this prop. Not asking for a particular internal refactor of DataPage's context object;
the memoization observation above is a lead, not a requirement.

[woksin]

Fixed in #169.