Add an i18n scaffold and extract hardcoded English strings

[knytcomics-ui]

Summary

Every user-facing string (tier labels/messages in tiers.ts:10-47, button text and status copy in TierWarning.tsx/App.tsx) is hardcoded English inline, with no translation infrastructure -- a barrier to reaching non-English-speaking Stellar users.

Current Behavior / Relevant Code

• src/lib/tiers.ts:10-47 (label, message fields).
• src/popup/TierWarning.tsx:23-33.
• src/popup/App.tsx:69-96 (loading/error copy).

Why This Matters

Security warnings are exactly the content where comprehension matters most -- a non-native-English speaker misreading or skimming past a warning because it's not in their language is a real harm this product exists to prevent.

Proposed Solution

• Introduce a lightweight i18n library (e.g. react-i18next or a minimal custom key-lookup) and extract all user-facing strings into locale resource files, starting with en.
• Wire tierForScore's output to reference message keys rather than hardcoded strings, resolved at render time.
• Keep scope to scaffolding plus English extraction; additional locales can be separate follow-up issues.

Acceptance Criteria

• No user-facing string is hardcoded directly in component/logic files -- all route through the i18n layer.
• Existing tests updated to work against the new string-resolution mechanism.
• README documents how to add a new locale.

Definition of Done

• npm run lint, npm run typecheck, npm test, and npm run build all pass locally and in CI
• New or changed behavior is covered by unit tests (and integration/E2E tests where the change touches interception, background messaging, or the popup)
• Any user-facing or architectural change is reflected in README.md
• No regressions to the existing test suite or existing tier/interception behavior

How to Claim This Issue (Application Process)

1. Comment first. Post a short implementation plan on this issue — your proposed approach, the files you expect to touch, and any open questions — before writing code. This prevents duplicate effort and lets a maintainer flag concerns early, which matters especially for an issue at this complexity level.
2. Wait for assignment. A maintainer will review your plan and assign the issue to you, typically within 48 hours. Please do not open a draft PR before you're assigned.
3. Stay active. If there's no visible activity (commits or comments) for 10 days after assignment, the issue may be unassigned and reopened to other contributors.
4. Submit a scoped PR. Reference this issue (Closes #<issue-number>), keep the diff scoped to the acceptance criteria above, and ensure all CI gates pass before requesting review.
5. Engage with review. Respond to review feedback within a reasonable timeframe; PRs with no response after 7 days may be closed pending resubmission when you're ready to pick it back up.

---

Category: Popup UX & Accessibility
Estimated effort: M (medium, ~3-5 days)
Difficulty: Advanced — this issue assumes familiarity with the codebase's MV3 service-worker architecture, the Freighter interception protocol, and/or the Stellar SDK.

[Heazzy500]

Hello, I’ve gone through the requirements and I’m confident I can implement a proper solution that matches the acceptance criteria. Kindly assign this issue to me.

[grantfox-oss]

🦊 GrantFox — @mordabdul1 has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #36)
2. Your PR will be reviewed by the Gryd-lock maintainers

Good luck! Track your progress on GrantFox.