Exploring moving documents to `core-data`

A collection’s documents (aka rows) read and write outside core-data, even though they’re `crtxt_document` like pages, which already go through core-data. So the grid, the side peek, and the full-page editor each keep their own copy, and we sync them by hand with a few hundreds of lines that only exist to cover for the missing shared store.

**Proposed solution:**

The first step would be the biggest win: write fields through `saveEntityRecord`, and read document records from core-data in the grid, leaving `/cortext/v1/rows` to do nothing but return the ordered, filtered list of IDs. Once every surface reads the same record, the sync is automatic, optimistic edits behave as they do for pages, and field saves rejoin the editor autosave.

In a second, optional step, we could move the list query itself (filter, sort, search, manual order, pagination) onto the core endpoint so `useEntityRecords` runs it, and drop the custom query layer. This is the hard part, blocked on expressing those queries through `WP_Query` and a per-field-type capability contract. I'm not too sure this is actually worth touching unless the ID-list endpoint becomes a maintenance burden.

The biggest risk to watch out for is invalidation keys in the ID-list query, which could cause `EditorProvider` and the grid to resolve the same records and prevent saveEntityRecord from fighting the editor's autosave.

No file paths or tests are named. Start by tracing collection document reads and writes across the grid, side peek, and full-page editor, then inspect saveEntityRecord, useEntityRecords, /cortext/v1/rows, and EditorProvider invalidation behavior. Done means the surfaces share core-data records without conflicting autosave or invalidation behavior; the optional query migration remains a separate decision.

Written by the indexing model from the issue text.