chore(plugin-multi-tenant)!: remove deprecated APIs

[paulpopus]

• Removes three deprecated APIs from @payloadcms/plugin-multi-tenant and adds codemods + migration guide entries for each
• useBaseListFilter per-collection option renamed to useBaseFilter; codemod (migrate-multi-tenant-use-base-list-filter) auto-migrates
• tenantSelectorLabel plugin option removed in favour of i18n.translations['nav-tenantSelector-label']; codemod (migrate-multi-tenant-tenant-selector-label) auto-migrates locale-keyed objects, emits a manual-migration note for string values or configs that already have i18n
• getGlobalViewRedirect basePath argument removed; function now derives the redirect path internally from the Payload config
• Drops the custom tenantFieldValidate function from the tenant field — Payload's built-in required: true already rejects null, undefined, and empty arrays on hasMany relationship fields, making the custom validator redundant; validate is now excluded from RootTenantFieldConfigOverrides

Breaking changes

API	Removed	Replacement
collections[slug].useBaseListFilter	✓	collections[slug].useBaseFilter
tenantSelectorLabel	✓	i18n.translations[locale]['nav-tenantSelector-label']
getGlobalViewRedirect({ basePath })	✓	Remove argument; path derived internally
RootTenantFieldConfigOverrides.validate	✓	Not replaceable; use required: true (default)

[github-actions]

📦 esbuild Bundle Analysis for payload

This analysis was generated by esbuild-bundle-analyzer. 🤖
This PR introduced no changes to the esbuild bundle! 🙌

[paulpopus]

/ai-review

[github-actions]

Issues

Minor (nice to have)

• [packages/plugin-multi-tenant/src/fields/tenantField/index.ts:114] — The new tenantFieldValidate function is now always set as validate on the field, but required: true is also set. These two can conflict: Payload's built-in required validation runs alongside any custom validate function, but the custom validate here also enforces the required invariant redundantly. More importantly, validate was previously overrideable from _overrides (the old code accepted and threaded validate through fieldValidation), but now the validate key has been removed from the destructure and the external override is silently dropped. If a user previously passed validate in _overrides, it is now ignored without any warning — this is a subtle behaviour change worth documenting or explicitly excluding from RootTenantFieldConfigOverrides.

• [packages/plugin-multi-tenant/src/types.ts:215] — 'validate' has been added to RootTenantFieldConfigOverrides but the implementation no longer accepts it (it was removed from the _overrides destructure). The type now advertises an option the runtime silently ignores. Either honour the override or remove 'validate' from this union.

• [packages/codemod/src/transforms/migrate-multi-tenant-tenant-selector-label/index.ts:12] — The .filter() call pre-filters for wasForgotten() === false, but the inner loop immediately re-checks prop.wasForgotten() again. The second guard is redundant. This is harmless but adds noise — remove the inner if (prop.wasForgotten()) { continue } (lines 18–20).

• [packages/codemod/src/transforms/migrate-multi-tenant-tenant-selector-label/index.ts:75] — The generated replacement text i18n: { translations: { ${localeEntries.join(', ')} } } produces a single-line object regardless of the original formatting style. This is fine for a codemod (users are expected to reformat), but it is worth noting that the output fixture (object.output.ts) reflects this by having the entire i18n block on one very long line, which may surprise users. Consider adding a brief note in the README that users should run their formatter after applying the codemod.

Recommendations

The removal of useBaseListFilter and tenantSelectorLabel is clean and the codemods are well-structured with idempotency tests and no-match guards. One broader point: the tenantFieldValidate refactor (collapsing fieldValidation into a simple top-level const) is a good simplification, but the interaction between required: true and the custom validate function should be resolved — either keep required: true and drop the custom validate (relying on Payload's built-in required enforcement), or keep the custom validate and drop required: true to avoid double-validation. As it stands both run, which is harmless but redundant.

Assessment

Ready to merge? Yes with fixes

Reasoning: The breaking-change removals, codemods, and documentation are all consistent and well-tested. The only material concern is the mismatch between the 'validate' entry added to RootTenantFieldConfigOverrides and the runtime code that now silently ignores any user-supplied validate override — this should be resolved before merge to avoid a confusing developer experience.