Lexical BlocksFeature: block-owned availability callback with parent editor context

[cbratschi]

Problem

BlocksFeature currently accepts a static list of blocks. That works for a
flat editor, but becomes difficult when reusable blocks contain their own
Lexical fields and only certain nesting combinations are valid.

For example:

• a two-column block should not be available inside another two-column block;
• tabs may allow accordions but not another tabs or two-column block;
• an alert may contain rich text but should not expose layout blocks;
• the same blocks are reused in several root editors.

BlocksField.filterOptions does not cover this case. It belongs to an ordinary
Blocks field, is based on document/form data, and does not receive the chain of
enclosing Lexical editors. BlocksFeature still only exposes static blocks
and inlineBlocks arrays on current main.

Current workaround

We currently pass a custom context through every editor and rebuild blocks that
contain rich-text fields for every allowed nesting path. Each such block needs
a global definition plus a child-block factory. The factory accumulates denied
block slugs, tracks the block stack, prevents recursion, and creates another
editor configuration for the next level.

With five blocks containing nested editors, our current rules expand one full
root editor into 34 contextual block objects and 36 editor configurations,
before Payload performs its own schema and client-config traversal. More
importantly, availability rules are spread across parent factories and every
new reusable block has to participate in this custom construction protocol.

This resembles the depth-limited recursive factory pattern discussed in #4238.
Issue #17302 is a separate GraphQL bug, but it demonstrates another cost of
representing each depth as a different block configuration.

Proposal

Could a block declare a Lexical-specific availability callback that receives
the current editor and an ordered list of parent editors?

The exact naming and location are open, but conceptually:

type LexicalEditorLocation = {
  blockSlug?: BlockSlug
  fieldName: string
  schemaPath: string
}

type LexicalBlockAvailabilityArgs = {
  editor: LexicalEditorLocation
  parentEditors: readonly LexicalEditorLocation[]
}

const TwoColumnsBlock: Block = {
  slug: 'twoColumns',
  lexical: {
    isAvailable: ({ editor, parentEditors }) =>
      ![...parentEditors, editor].some(({ blockSlug }) =>
        blockSlug === 'tabs' || blockSlug === 'twoColumns',
      ),
  },
  fields: [/* ... */],
}

All editors could then reference the same global block slugs. A block would own
rules that are intrinsic to its structure, while an editor-level allowlist or
override could still handle one-off restrictions.

I think this is complementary to the rationale in #13801. Document-specific
availability belongs to the field, but a reusable block is the best place for
a rule such as “this layout block can never be nested below tabs or itself.”
Otherwise every editor that consumes the block has to repeat knowledge about
that block.

Behavior that would matter

1. parentEditors should expose stable structured information such as the
   enclosing block slug and field/schema path, ordered from the root to the
   nearest parent.
2. The rule should be applied at every nested editor level without requiring
   applications to clone or rebuild block definitions.
3. An unavailable block should disappear from the slash menu and fixed toolbar.
4. The same rule should be enforceable for Local and REST API writes, while an
   existing stored node remains renderable so invalid legacy content can be
   corrected.
5. The implementation should not eagerly expand another complete block graph
   for every possible parent path, because that would reproduce the current
   workaround inside Payload.
6. Inline blocks should eventually receive the same context.

The client already has a parentEditor chain in EditorConfigContext, but the
server editor/provider path does not currently receive equivalent context. I am
not sure whether the cleanest implementation is to make that context available
during feature resolution, to resolve insertion availability later, or to use
a split server/client representation. I would first like feedback on the API
direction and expected validation semantics.