Evaluate internationalization scope for user-facing project outputs

## Context

OpenSSF Best Practices silver criterion `internationalization` suggests that project software be internationalized where it generates text intended for end users or sorts human-readable text.

Registry Stack currently has English-only public docs and visible CLI/operator text. The project has not yet defined which outputs should be localizable, which outputs are operator-only, and which are out of scope.

## Scope

- Inventory user-facing and operator-facing generated text across docs, CLI, demos, and product services.
- Decide which surfaces should support localization and which are intentionally English-only for now.
- Document the decision publicly.
- If localization is in scope, define the message catalog or translation workflow before broad implementation.

## Done when

- The Best Practices `internationalization` answer has a clear public justification.
- Any future localization work has an agreed scope and implementation path.

## Non-goals

- Do not start broad translation work before the target surfaces and maintenance model are defined.

Start by inventorying generated text across the docs, CLI, demos, and product services, then read the OpenSSF Best Practices internationalization criterion. Document which surfaces are localizable or intentionally English-only, and define the message catalog or translation workflow if localization is in scope; done means the public justification and future implementation path are agreed.

Written by the indexing model from the issue text.