Customizing's first consumer (partner catalogs)

The Customizing engine's first real consumer, plus the i18n tooling that pairs with it.

Added

• Partner-role + relationship-type catalogs are now code-owned Customizing — the first real consumer of the engine. New Partners\Attributes\PartnerRole + Partners\Attributes\RelationshipType (both CustomizingEntry, distinct from the existing Partners\Models\*), Partners\Enums\PartnerRoleCode + Partners\Enums\RelationshipTypeCode, and the SDK-generic baseline declared on PartnersModule: 9 roles (supplier/employee/department/cost_center + bill_to/ship_to/payer/approver/project_lead) and 2 relationship types (employed_by, owns). They land in sdk_partner_roles / sdk_partner_relationship_types on ui5:sync — every install gets the baseline for free, no host seeding. Lifecycle codes (lead/prospect/customer/churned, …) remain host-specific.
• ui5:i18n command — expands the i18n keys for the synced Customizing catalogs into a base .properties bundle (customizing.<catalog>.<code>.<column>, seeded with the source-language literal). Base-only (never a localized *_<locale>.properties — that's the translators' domain) and append-only (safe to re-run; never duplicates or overwrites a refined label). --out sets the target (default resources/ui5/i18n/db.properties, a refresh-safe bundle so ui5:app --refresh can't clobber it). v1 covers the Customizing family; the cross-cutting expansion of Roles / Settings / Act / Access is the documented next step.

Customizing engine (contract + capture)

Two steps toward the SDK Customizing surface (sdk-customizing-v0.9.md): the code-owned reference-catalog projection that lifts vocabularies like partner roles out of host seed migrations onto ui5:sync, plus a layering cleanup of the sync workers.

Added

• Customizing\Contracts\CustomizingEntry — the meta-interface a Customizing attribute class fulfils (e.g. a host's #[PartnerRole]): the static catalog shape (catalog() / table() / identityColumn() / translatable()) split from the per-row data (identity() / columns()). Codes are BackedEnum|string; identity() dissolves an enum to its scalar ->value. This interface is the one frozen seam of the Customizing surface. Consumers ship their own attributes against it.
• SdkRegistry::customizing() + the registerCustomizing() capture pass in afterLoad() Pass 1. A single reflection sweep (ReflectionAttribute::IS_INSTANCEOF) discovers every CustomizingEntry attribute declared across modules, grouped by physical table (descriptor + rows), with a hard duplicate-identity guard. Sync-time data like roles() / abilities() — intentionally not exported to the registry cache.
• Customizing\CustomizingWorker — the generic flat projection of every declared catalog. For each table it reconciles the DB to the complete declared set (insert / update-if-dirty / delete-absent), keyed on the catalog's identity column, column-agnostic, via the query builder (no per-catalog model); it stamps created_at/updated_at only when the table carries them. Wired into SyncService after RolesWorker (FK-independent). Inherits the pipeline's one-transaction / dry-run / fail-loud contract; a delete blocked by an ON DELETE RESTRICT from a configuration table bubbles loud rather than being swallowed.

Changed

• Sync workers relocated into the domains they project. ArtifactsWorker, AbilitiesWorker, RolesWorker moved Sync\Workers\ → Security\; SettingsWorker → Settings\. The worker now lives with the model/table it writes, reversing the old Sync → domain-model dependency. Sync\ keeps only the orchestration (SyncService, SyncPipeline, the contexts, SyncWorkerInterface); SyncService still wires the hardcoded worker list in FK order — no registration seam added, so the Sync spec's D2 holds. (Internal relocation: the four worker classes are @internal; no public contract changed. In-house consumers only.)