i18n provider: translatable plugin UI strings with English defaults

[olliethedev]

Context

Part of the Refine-inspired core simplification effort (#127 ✅, #128, #129, #130 ✅, #131, #133). Refine's i18nProvider + useTranslate pattern: components call t(key, defaultValue), consumers optionally plug in their i18n library. Without a provider, defaults render — zero setup cost.

Scope note: this issue covers the core provider only (phase 1). Converting each plugin's UI strings to t(key, default) is tracked in #136 (phase 2), done during each plugin's sweep.

Problem

All plugin UI strings — buttons, labels, empty states, dialogs, validation and toast messages — are hardcoded English. Non-English consumers cannot localize plugin UIs, and retrofitting keys only gets more expensive as plugins grow.

Proposal

An optional i18n provider on StackProvider:

<StackProvider
  i18n={{
    translate: (key, defaultValue, params) => t(key, { defaultValue, ...params }),
    // optional: getLocale, changeLocale
  }}
  ...
>

• useTranslate() from @btst/stack/context; without a provider it returns the default value — non-breaking, no consumer setup
• Namespaced keys per plugin: t("blog.posts.create", "Create Post")
• Interpolation: t("blog.posts.deleted", "Deleted {{title}}", { title })
• Notification messages (Notification provider: pluggable notify() instead of hardcoded sonner toasts in every plugin #131) and meta/SEO defaults flow through the same translate

Scope (core only)

• i18n prop on StackProvider + useTranslate() hook with default-value fallback + interpolation
• Unit tests: fallback behavior, interpolation, provider receives key/default/params
• Key extraction script or convention check (so Phase 2: per-plugin adoption sweep of the new core primitives #136 sweeps produce a complete key reference)
• Docs: StackProvider reference + integration examples (next-intl, i18next)

Acceptance criteria

• Apps without an i18n provider render identical strings
• A consumer-provided translate receives key, default, and params for every call through useTranslate()
• Key extraction produces a per-plugin reference of keys + English defaults (validated on the first migrated plugin in Phase 2: per-plugin adoption sweep of the new core primitives #136)

Per-plugin string conversion → #136.