note the provider requirement shared components now carry, under open question 3

Found while converting them in phase 1: they resolve against whatever provider is
above them and render dot-paths with none. Safe today only because the second React
root imports nothing from components/. Written where the plugin-contract decision
will be made rather than solved here.

docs/localization.md

@@ -360,6 +360,19 @@ else will ever notice.
    obvious first pass. Any locale beyond Portuguese needs an answer to this before it is offered.
 3. **Plugin frontends** are out of scope and will need a catalog-merging contract in the plugin
    manifest. Their strings are not counted above.
+
+   **One constraint that contract has to answer, found while converting the shared components
+   (2026-08-23):** those components now call `useTranslation`, so they resolve against whatever
+   `I18nProvider` is above them — and with none above them they render their own dot-paths. Today that
+   is safe by accident: there are exactly two React roots, and the one that is not `officer-web`
+   (`apps/marketplace`) imports nothing from `components/`. A plugin frontend mounting its own root, or
+   rendering a shared component outside `I18nBridge`, would put `ui.button.cancel` in front of a person.
+
+   So the contract needs to say where a plugin's provider comes from — inherit the host's, or mount its
+   own seeded with the host's catalogs — rather than leaving each plugin to remember. Note that a
+   provider-absent fallback inside the `components` package was considered and rejected: it would have
+   split resolution across two mechanisms and contradicted D6, which puts the merge at the bridge.
+
 4. **The `translateTo` setting already in `settings.languages`** is about translating _content_, not
    the UI. It is a different feature that happens to sit in the same object — do not conflate them.
 5. **Does a member see the owner's locale anywhere?** Any server-rendered or cached string shared