i18n: extract the Home child components (en + zh-CN)

[Janlhin]

Follows the pattern from #19 and extracts the rest of the Home screen — the
ten child components under views/home/.

Included

• ScanDialog, ScanFolderList, SetupGuide
• LibraryGrid, LibraryTile, LibraryViewOptions
• HomeSummary, AddGameCard, OfferedGames, RecentActivity

Home is now fully translated end to end (146 new keys; both catalogs at 167).

Conventions kept from the review in #19

• One sentence per key. Where part of a sentence is bold (a game name, a
  branch, a path), it stays one key with a {placeholder} rendered through
  segments() — three places here.
• Counts go through Intl.PluralRules (home.scan.trackedGames,
  home.scan.foundInFolders, home.scan.oneSave, home.scan.foundSummary,
  home.tile.snapshots, home.library.bulkDone, home.offered.intro).
• Keys are grouped per component (home.scan.*, home.library.*, …).

Two judgement calls, easy to change if you'd rather not

1. A few strings repeat across components, so I put them in a small
   common.* group (common.cancel, common.nowTracking) instead of
   translating the same wording twice. Where a value already existed
   (home.devices, home.scanning, home.chooseFolderDialog,
   home.welcome.scanForSaves) I reused that key rather than adding a
   duplicate.
2. Labels that live in lib/ are still English: libraryview.js cover
   styles and tile sizes, gamestatus.js sort names and status text,
   timeago.js, syncpause.js. They return single words, not sentences, so
   they need a pass that has them hand back keys for the component to render
   — I left that out to keep this one reviewable. Say the word and I'll do it
   as its own PR.

One thing left as typed on purpose: the Windows example path in
AddGameCard's placeholder (C:\Users\you\AppData\…) — translating it would
make it a worse example.

Checks

• npm test: 271/271 (catalog completeness, placeholder parity, no missing
  or extra keys)
• vite build: clean

Happy to rebase onto a newer i18n whenever you'd like — I noticed i18n is
still a few commits behind dev (2.4.1) and didn't want to move it myself.

[vercel]

Someone is attempting to deploy a commit to the sivadaboi's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Janlhin]

Rebased onto dev as suggested — the branch now sits on 2.4.2 instead of the
older i18n base.

Clean rebase, no manual fixes needed: the only file the two histories share
is views/home/OfferedGames.svelte, and the dev side of that is comment-only
(it documents the CVE-2026-103398 folder rule), so it merged on its own.

• 3 commits replayed on top of dev
• npm test: 282/282
• Catalog re-checked after the rebase: 167 keys in both en.json and
  zh-CN.json, no missing or extra keys, placeholder sets matching

I'll base the follow-up view PRs on dev as well, and rebase again if 2.4.2
grows before you get to this. Not a rush on my side.

[Janlhin]

Correction to the note above — I tried it, and rebasing this branch onto dev
makes the PR unusable, so I put it back.

The reason: this PR's base is i18n, not dev. Once the branch is rebased
onto dev, i18n is no longer an ancestor of it, so the diff suddenly
includes all 16 commits that dev is ahead — 70 files, +3367/−222 — and
locales/en.json / zh-CN.json come back as add/add conflicts against the
copies already merged in #19. Not something a review should have to untangle.

So: the branch is back where it was (12 files, +525/−161, mergeable), and
the rebased version is parked on my fork as rebase-onto-dev if it's useful
for picking the work up on a dev-based branch later.

What I think you mean, and what I'll follow from here: subsequent view PRs go
straight onto dev rather than i18n, so they sit on 2.4.2 and don't need a
rebase at review time. Say the word if you'd rather they keep targeting
i18n and you'll fold dev into it yourself.