feat: support slug fields nested within groups, arrays and blocks

[bastienrobert]

Which branch should this PR target?

main — Payload v4 development. New features, enhancements, and v4 bug fixes go here.

What?

The slug field only generates correctly at the top level of a document. useAsSlug is documented as naming a sibling field, but the hook reads the document root, so a slug nested in a group, array row or block derives from the wrong level or from nothing.

How?

useAsSlug now resolves against the slug field's siblings, and the stored value is read from previousSiblingDoc instead of originalDoc. At the top level siblingData and data are the same object, so nothing changes for existing configs.

eg.

{
  name: 'sections',
  type: 'array',
  fields: [
    { name: 'heading', type: 'text' },
    { name: 'slug', type: 'slug', useAsSlug: 'heading' },
  ],
}

Each row generates its own slug from its own heading, both on save and from the Generate button. The field config lookup now goes through the schema map (keyed by schema path), which fixes the crash and handles blocks.

Custom slugify functions now also get siblingData. To generate from a field that is not a sibling, use a custom slugify as it receives the full document data.

Uniqueness is root-only: every uniqueness path addresses a collection-wide field by name, which a nested slug does not have. So a nested slug defaults unique and required to false, and skips dedupe, the collision check and the -N fallback.

Breaking changes

• A slug nested in a group with useAsSlug pointing at a top-level field will stop resolving.
• A nested slug now defaults unique and required to false instead of true — an existing nested slug loses its unique index.
• Nested slugs are no longer deduped and get no -N fallback.

Builds on #17458.
Supersedes #14783.