v2.5.1

Bug Fixes

• @byline/richtext-lexical — Internal-link and inline-image populate batches now fetch their target documents through the storage adapter's getDocumentsByDocumentIds primitive instead of client.collection(path).find({ where: { id: { $in: ids } } }). parseWhere has no handler for id, so the previous shape silently dropped the filter and returned arbitrary documents ordered by created_at desc, capped at ids.length rows. In a single-published-doc target collection the broken query accidentally returned the right document; once a target collection contained more than one published document, embeds could resolve link envelopes against the wrong target (writing the wrong document.title / document.path) or trip the "internal link target not found" branch (marking the link _resolved: false even though the target existed and was published). Surfaced reliably after bulk-importing markdown through the import-docs script, where the docs collection grew past one published row. The fix mirrors the primitive populateDocuments already uses for ID-based batch fetches at packages/core/src/services/populate.ts, so richtext link populate and relation populate now share the same target-lookup path. Returned rows are normalised to the { id, path, status, fields } shape both visitors expect, so linkVisitor and inlineImageVisitor need no changes. readContext stays on the runLexicalPopulate options interface for forward compatibility but is no longer threaded — the direct adapter call doesn't recurse into populate or afterRead, so there is no visited-set or read-budget state to share. Companion ticket tracks teaching parseWhere to recognise id as a reserved key so where: { id } becomes a first-class client API surface (the CHANGELOG entry that referenced it previously was misleading).

All other @byline/* packages bumped to 2.5.1 in lockstep with no behavioural changes this cycle.