discourse-content-localization

Add `include Localizable` to the source model with a nullable `locale` column, then create a `<Model>Localization` table with `include LocaleMatchable`, translated fields matching source length limits, and a unique `(model_id, locale)` index. Use `get_localization` for fallback behavior instead of reimplementing it in serializers.

Preload localizations with `includes(:localizations)` on every list, boot, site JSON, admin, and controller path that serializes localized fields. Any serializer calling `get_localization` on hot routes like discovery pages must receive records with localizations already preloaded.

Automatic detection, backfill, and localizer jobs belong in `plugins/discourse-ai`, never in core. Core holds the data model, serializers, Guardian checks, and edit UI, while discourse-ai adds model-specific Candidate, Localizer, and scheduled backfill jobs.

Edit and settings surfaces must load source/default values, not localized display values. A Japanese admin opening the "Support" category settings should see the source name "Support", not its localized name, so serializers for edit payloads must return original fields plus localization rows.

Only users passing a Guardian localization check can edit localizations, enforced server-side. For admin-owned or global content, admin-only checks are preferred, and localization rows are exposed in API responses only to authorized editors.