I added a commit with the regenerated types.

The main thing I wanted to raise is the naming strategy for the generated types. Each rich-text field generates a type that lists every node it can contain (paragraphs, headings, links, blocks, and so on). That type is named LexicalNodes_<hash>, where <hash> is a fingerprint computed from the full contents of that list, so if any node in the editor changes, the fingerprint changes and the type gets a new name. The issue is that the type for a link's custom fields reuses that same editor fingerprint: today it takes the LexicalNodes_<hash> name and just swaps the prefix to produce LexicalLinkFields_<hash>. Because the name is tied to the fingerprint of the whole editor and not to the link fields themselves, adding an unrelated field to a block changes the editor fingerprint, which renames the link-fields type, which churns every reference to it. That is how a tiny change becomes a noisy diff. Upload fields already avoid this: they compute the hash from the upload fields' own content, so the name only changes when the upload fields change. Could we make link fields consistent with upload fields and hash them by their own content? That keeps the dedup and determinism but stops unrelated changes from cascading into LexicalLinkFields_* renames.

In this test, the assertion expect(generatedTypes).not.toContain('SerializedInlineBlockNode<{blockType: string}>') reads the generated output as plain text and checks that string is absent. The problem is the generator never emits that exact string: the real output is formatted differently (with spaces and a different shape, like SerializedInlineBlockNode<TFields extends { blockType: string }> for the declaration and SerializedInlineBlockNode<SomeBlock> for usages). A not.toContain for a string that can never appear always passes, so this test would stay green even if the bug came back. Could we assert against the shape the generator actually emits, so the test really guards the fix?

SerializedBlockNode / SerializedInlineBlockNode are written down twice: once as the real TypeScript types, and once as a hardcoded string that gets copied verbatim into every user's generated payload-types.ts. The two must be identical (there is even a comment saying they "MUST stay byte-for-byte in sync"), but nothing enforces it: if someone edits one and forgets the other, the type users receive in their generated file silently drifts from the real one. Could we add a small test that asserts the emitted string matches the runtime type, so this can't break unnoticed?