feat(cli): centralize user-facing text to prepare for internationalisation

[LMLiam]

Scope: localization-prep

Executive Summary

Centralize user-facing product text so Microsmith can support future internationalisation without invasive command-by-command refactors.

Problem Statement

User-visible strings are currently spread across commands, diagnostics, onboarding flows, templates, and supporting tooling. That increases copy drift, makes consistency harder to enforce, and creates unnecessary friction for future localisation work.

Objectives

• Centralize user-facing text behind a single message source or abstraction.
• Make command logic independent from hard-coded English strings.
• Prepare the codebase for future locale selection without shipping translations yet.

Non-Objectives

• Shipping non-English translations in this issue.
• Localising user-owned project content or arbitrary generated application code.

Functional Requirements

• Introduce a centralized message catalog or equivalent abstraction for user-facing product text.
• Cover CLI help text, diagnostics, onboarding output, remediation guidance, and other product-owned runtime messages.
• Replace scattered inline user-facing literals in core flows with catalog-backed message keys.
• Support parameterized messages without embedding formatting logic into command handlers.
• Define a locale-resolution seam with English as the default baseline.
• Document conventions for adding new user-facing text so future changes remain centralized.

Non-Functional Requirements

• Message handling must be maintainable and testable.
• Centralization must not materially degrade runtime UX or command performance.

Security Considerations

• Centralized formatting must preserve safe handling of paths, commands, and sensitive values in diagnostics.
• Secret-bearing values must remain redacted consistently across all messages.

Operational Readiness

• Add contributor guidance for where product text belongs.
• Add checks or review guidance to prevent new scattered user-facing literals in core surfaces.

Backward Compatibility and Migration

• Default user-facing output remains English unless a future locale feature is introduced.
• Existing command behavior remains functionally unchanged aside from intentional copy normalization.

Observability and Metrics

• Count of remaining uncatalogued user-facing strings in covered modules.
• Regression tracking for missing-key or malformed-message failures.

Risks and Mitigations

• Text regressions during extraction: use snapshot and contract tests for critical command output.
• Partial adoption leaving mixed patterns: define mandatory coverage boundaries and enforce them in review.

Acceptance Criteria

• Core user-facing text is sourced from a centralized message layer rather than scattered literals.
• New core flows do not introduce raw user-facing strings outside the approved abstraction.
• Default English output remains stable and test-covered.
• The codebase can add locale selection later without restructuring command logic again.

Test Strategy

• Unit tests for message lookup and parameter substitution.
• Snapshot or contract tests for representative command output and diagnostics.
• Static checks or targeted scans for uncatalogued user-facing literals in covered modules.

Dependencies

• Coordinates with: feat(validation): add docs, fixtures, and validation matrix for runtime, onboarding, and IDE flows #49, feat(onboarding): add one-command bootstrap for non-JVM repositories #52

Definition of Done

• User-facing product text is centralized, documented, test-covered, and ready for future localisation work.