getFilteredRowModel().flatRows is post-order, same bug #6529 just fixed for getSortedRowModel

[MILLERMARRU]

getFilteredRowModel().flatRows has the exact same post-order bug that #6529 just fixed for getSortedRowModel().flatRows, and the PR itself flags it as a known follow-up that wasn't in scope there.

From #6529's description:

filterRowModelFromLeafs and filterRowModelFromRoot flatten the same way, so getFilteredRowModel().flatRows is post-order too. I left those alone... That felt like a bigger behavioral call than this fix, happy to do it in a follow-up if you'd like it changed.

I checked filterRowsUtils.ts on current main and both paths still push children before their own parent:

filterRowModelFromLeafs recurses into row.subRows first (newRow.subRows = recurseFilterRows(...)), and only pushes the row to newFilteredFlatRows after that call returns, so descendants land in the array first.

filterRowModelFromRoot (the default, filterFromLeafRows: false) looks parent-first at a glance, but the recursive call newRow.subRows = recurseFilterRows(row.subRows, depth + 1) runs and pushes the children to the shared newFilteredFlatRows closure before the parent's own newFilteredFlatRows.push(row) a few lines later executes. Same net effect, children first.

Repro, mirroring the one in #6529:

const table = useReactTable({
 data,
 columns,
 getSubRows: row => row.subRows,
 getCoreRowModel: getCoreRowModel(),
 getFilteredRowModel: getFilteredRowModel(),
 state: { columnFilters },
})

// two parent rows with sub-rows, both passing the filter
table.getCoreRowModel().flatRows.map(r => r.id)
// ['a', 'a1', 'a2', 'b', 'b1']

table.getFilteredRowModel().flatRows.map(r => r.id)
// ['a1', 'a2', 'a', 'b1', 'b'] <- descendants before their own parent

This disagrees with rows (already in render order) and with getCoreRowModel/getPaginatedRowModel, which both push parent-first. It matters concretely for column_getAutoSortFn/column_getAutoFilterFn, which sample getFilteredRowModel().flatRows.slice(0, 10) to auto-detect a column's data type, same concern #6529 raised for why it didn't touch this itself.

Since #6529 already explains the mechanism and offers to follow up, this issue is just to have something to track and link a PR against, rather than leaving it as a comment buried in an unrelated PR.