feat: add injectable StringFormatter + Slugify features (app-admin)

[adrians5j]

Problem

The slugify npm package was imported directly across many admin presenters, each repeating the same options object. Slug generation could drift, and projects had no supported way to override it — some resorted to intercepting it at the bundler level.

Solution

Two injectable, decoratable features in @webiny/app-admin:

• StringFormatter — the consumer-facing string-transform API (parallel to DateFormatter). Its methods will grow over time; today it exposes slugify().
• Slugify — a small, single-method feature (execute()) holding Webiny's canonical slug options.

StringFormatter.slugify() delegates to Slugify.execute() internally. Consumers use StringFormatter; to change slug logic a project decorates Slugify alone — a smaller surface than decorating the whole formatter. Both register with the core admin features (always available); StringFormatterFeature registers Slugify as its internal dependency.

The abstractions take (value) => string — no options bag. The canonical options are a private detail of DefaultSlugify, so the contract stays independent of any specific slug library. A project changes behavior by decorating, not by passing per-call options.

Design (per Slack thread)

pavel: if we have DateFormatter, can we have StringFormatter instead, with slugify() as one method?
Adrian: having Slugify alone is easier to decorate than StringFormatter … so users use StringFormatter, and to change slugify logic they decorate Slugify alone.
Bruno: so stringFormatter.slugify() uses slugify.execute() internally? — yeah. 👍 pavel: sold.

Migrated (DI-connected, user-facing form-slug generation → StringFormatter)

• app-admin: RolesPresenter, ApiKeysPresenter, TeamsPresenter
• app-aco: FolderTreePresenter, folder create dialog (useCreateDialog)
• app-headless-cms: ModelGroupPresenter
• Dropped the now-unused slugify dependency from app-aco and app-headless-cms.

Override (per project) — decorate the fine-grained seam

const MySlugify = Slugify.createDecorator(() => {
    return {
        execute: value => {
            return value.trim().toLowerCase().replace(/\s+/g, "_");
        }
    };
});

container.registerDecorator(MySlugify);

Left as-is on purpose

• app-website-builder experiment toKey — uses strict options ({ lower: true, strict: true }) to generate internal experiment keys; kept as direct slugify usage for now (see TODO).
• PagePath / pagePathFromTitle — pure value objects / publicly-exported utils with no DI seam.
• @webiny/form useGenerateSlug — base-layer package that cannot depend on @webiny/app-admin.

TODO / follow-ups

• Last toKey call site — bring the app-website-builder experiment toKey into the feature system. It is a distinct transform (strict machine key, not a display slug), so it should become its own method on StringFormatter (e.g. toKey()) backed by its own fine-grained feature — not a bare slugify call. Tracked as a follow-up so this PR stays focused.
• Backend (separate PR) — make the same utilities available server-side from @webiny/api-core: recreate DateFormatter and StringFormatter / Slugify using api-core's DI, so backend code gets the same injectable, decoratable formatting.

Testing

• yarn check ✓ for app-admin / app-aco / app-headless-cms
• Tests: app-admin 436, app-aco 93, app-headless-cms 25 — all pass.
• yarn lint / yarn format / yarn adio ✓

🤖 Generated with Claude Code