feat: add configurable unique rule modifier for section edit action

[ManukMinasyan]

Allow applications to register a custom unique rule modifier via resolveUniqueRuleModifierUsing() to scope section name/code uniqueness validation during edit, preventing false "already taken" errors.

[Copilot]

Pull request overview

Adds an application-configurable hook to modify the section edit action’s uniqueness validation rule, enabling custom scoping to avoid false “already taken” errors when editing sections.

Changes:

• Introduces a static resolver (resolveUniqueRuleModifierUsing) to provide a per-section unique-rule modifier.
• Applies the resolved modifier to SectionForm before building the edit action schema.
• Refactors edit action schema construction to reuse a configured SectionForm instance.

[Copilot]

New behavior is introduced here (a resolver that can alter the unique-rule used by the edit action), but there’s no test asserting it’s applied and affects validation outcomes. Please add a feature test around callAction('edit', ...) that registers resolveUniqueRuleModifierUsing() and verifies the resulting unique validation is scoped as intended (and that the resolver is cleared/reset between tests).

[Copilot]

Because the resolver is user-provided, it can accidentally return a non-Closure value; in that case this will currently fail with a TypeError when calling modifyUniqueRuleUsing(). Consider validating the return value explicitly (e.g. apply only when it’s an instance of Closure, and throw a clearer InvalidArgumentException when a non-null, non-closure value is returned) to make misconfiguration easier to diagnose.

Suggested change

	if ($modifier) {
	$sectionForm->modifyUniqueRuleUsing($modifier);
	if ($modifier instanceof Closure) {
	$sectionForm->modifyUniqueRuleUsing($modifier);
	} elseif ($modifier !== null) {
	throw new \InvalidArgumentException(sprintf(
	'The unique rule modifier resolver for [%s] must return a Closure or null, [%s] returned.',
	static::class,
	get_debug_type($modifier),
	));

[Copilot]

The PHPDoc for $uniqueRuleModifierResolver is too vague (and doesn’t match the closure-shape style used elsewhere, e.g. SectionForm::$modifyUniqueRuleUsing). Since this resolver is expected to return the callback passed into SectionForm::modifyUniqueRuleUsing(), the doc should spell out the nested closure signature (e.g. Closure(CustomFieldSection): (Closure(Unique, Get): Unique)|null) so consumers and static analysis know what to return.

[Copilot]

Exposing this configuration hook on a Livewire component (ManageCustomFieldSection::resolveUniqueRuleModifierUsing()) makes the package API harder to discover and ties configuration to UI implementation details. Consider moving this registration to a central configuration surface (e.g. CustomFields or SectionForm) and having the Livewire action read it from there, so apps don’t need to reference a Livewire class just to adjust validation scope.