frontend: Split Settings page into tabbed sub-pages

[santichausis]

Summary

Closes #256.

The Settings page had grown into a single ~560-line component mixing account info, profile, timezone, sustaining membership, MFA devices, and API keys. This splits it into four tabs, each in its own component:

• Profile — account email/newsletter, first/last name, default timezone, save button (SettingsProfile.jsx)
• Security — MFA devices table (SettingsSecurity.jsx)
• API Keys — API keys table (SettingsApiKeys.jsx)
• Billing — sustaining membership, only shown when Config.sustainingMembership.enable is true (SettingsBilling.jsx)

Settings.jsx is now a thin container: breadcrumbs, heading actions (change email/password, delete account — these stay global since they're account-wide, not tab-specific), and the tab bar. Each tab component only mounts (and fetches its data) when selected, rather than all four fetching eagerly on every page load as happened with the original single-loading-gate design.

This follows the existing local-state Tabs pattern already used in JobEditor.jsx and JobTestRun.jsx, rather than introducing routed sub-pages — happy to switch to /settings/security-style routes instead if you'd prefer deep-linkable tabs.

New i18n strings (settings.tabs.*) were added to en and de only, following the convention from recent PRs (#421, #423, #429, #441) — other locales will fall back to English until translated.

Test plan

• npm test — all 141 existing tests pass (pre-existing, unrelated App.test.js failure due to a Jest/recharts ESM parsing issue, confirmed present on master too)
• npm run build — compiles cleanly, no new warnings
• Manually verified in the browser: all four tabs render correctly, switch correctly, and each dialog (change email/password, delete account, add/delete MFA device, create/edit/delete/show API key, manage subscription) opens with the right props
• Verified the "Add device" button on the Security tab is disabled until the user profile has loaded (previously the whole page was gated behind one loading check; since tabs are now split, this needed its own guard)

[pschlan]

Looks good in principle, however the first tab looks a bit odd UI-wise, since the tab header component visually attaches to the first box only. This is slightly confusing as it's not obvious that the other two boxes below are also part of the tab.

We should probably use a single box per tab and group contents by fieldsets instead of boxes, e.g. like in the job editor.

[santichausis]

Good catch, thanks. Fixed in e7f6126: the Profile tab now lives in a single Paper, with Account/Profile/Timezone grouped by fieldsets with legends, same pattern as the job editor. Security, API Keys and Billing tabs were already single-box, so no change needed there.

[pschlan]

Thanks, but I'm not really happy yet with how it looks and the inconsistency between the different tabs. But right now, I also don't have a good idea how to resolve it. Will have to spend some time experimenting.

[santichausis]

Sounds good, no rush. I'll keep an eye on this PR — happy to try out different layout approaches or run tests on my end whenever you have something you'd like to experiment with.