i18n: translate the rest of /my/** and add es/pt/de/fr

[strelov1]

Context

#1998 landed the i18n infrastructure for the account section (locale resolution from users.language, path-gated to /my/**, the hand-rolled t()/defineMessages catalog mechanism) and fully translated /my/security, the shared shell/navigation (my/+layout.svelte, AccountNavRail), and the /my/profile tab-strip labels — English + Russian only. This was deliberately scoped as the reference pattern; see openspec/changes/i18n-my-account (now archived) for the full design rationale.

Two things are explicitly deferred there and still open:

1. Fan out to the remaining /my/** pages (en/ru)

Still English-only:

• /my/profile's eight tab views (ProfileForm, ExperienceBankView, CandidateContactsEditor, EducationCard, LocationCard, SkillsCard, ScreeningAnswersForm, AccountPreferences) — only the tab labels were translated in i18n infra + /my/security, shell nav, and profile tabs (en/ru) #1998
• /my/activity
• /my/tracking
• /my/inbox
• /my/market-pulse
• /my/assistant
• /my/cvs
• /my/referrals
• /my/notifications
• /my/api-keys
• /my/submissions
• /my/contributions
• /my/credits

Pattern to follow (established in #1998): a colocated messages.ts per page/component via defineMessages(en, ru), rendered through t(messages, locale()) from $lib/i18n/t.ts / $lib/i18n/currentLocale.svelte.ts. Keep the same scope-boundary rule: only translate a component if it's exclusively reachable from /my/** (or its locale reads page.data.locale, which is already path-gated, so it's safe even for components shared with a public route).

2. Add es/pt/de/fr

users.language already accepts es/pt/de/fr (same CHECK constraint as en/ru), and the account language picker already offers them — they currently render the /my/** interface in English via t()'s per-key fallback (working as designed, not a bug). This needs an actual translation pass once the en/ru pattern has stabilized across more pages, adding a third+ argument set to defineMessages per catalog (or extending it to accept an arbitrary locale map — worth revisiting the t.ts API shape once more than two target locales exist).

Suggested order

1. Finish the en/ru fan-out (item 1) — proves the pattern holds across more page shapes (forms, lists, streaming/SSE views like the assistant).
2. Only then add es/pt/de/fr, so translators work from a stable, complete English source rather than a moving target.