frontend: Add unit test coverage for untested helpers in src/helpers/

Problem

Several modules under frontend/src/helpers/ contain non-trivial logic but have no unit tests. They are imported across many parts of the app, so silent regressions in them (e.g., a corrupted localStorage payload, a container-fallback bug, an off-by-one in the dedup logic) are hard to spot.

The umbrella under #931 (Stories for components) covers visual / Storybook gaps; this issue tracks the same gap for the pure-logic helper modules.

Modules affected

File	LOC	Imported from	Logic worth pinning down
frontend/src/helpers/clusterSettings.ts	73	14 files	localStorage round-trip; empty-name no-op; key-prefix isolation; corrupt-JSON behaviour
frontend/src/helpers/podContainer.ts	77	2 files	getAllContainers (main + init + ephemeral concat); getDefaultContainer fallback chain (running main → running init → first main); resolveContainerName preferred-name match
frontend/src/helpers/recentClusters.ts	45	4 files	dedup on re-add, 3-item cap, string/Cluster-object polymorphism, non-array stored payload, corrupt JSON behaviour

Sibling helper tableSettings.ts already has tests at tableSettings.test.ts; the same pattern (Vitest, beforeEach(localStorage.clear()), nested describe-per-function) applies cleanly to the three modules above.

Proposed approach

One PR per helper (the three modules are unrelated logically — keeping them separate makes review and bisect cleaner):

1. frontend: clusterSettings: Add unit tests
2. frontend: podContainer: Add unit tests
3. frontend: recentClusters: Add unit tests

Each PR adds one new <helper>.test.ts file, no changes to production code, no new translation strings.

Out of scope (for this issue)

• Fixing the latent JSON-corruption behaviour in loadClusterSettings and getRecentClusters (both throw on malformed payloads rather than recovering). The tests will document the current behaviour with expect(...).toThrow(SyntaxError); a follow-up issue can decide whether to harden them.
• Adding tests to other untested helpers (getAppUrl.ts, getBaseUrl.ts, storage.ts etc.) — those are easy follow-ups but each has its own mocking concern (env detection, etc.) and is worth tracking separately.

Acceptance criteria

• frontend/src/helpers/clusterSettings.test.ts exists, all tests pass
• frontend/src/helpers/podContainer.test.ts exists, all tests pass
• frontend/src/helpers/recentClusters.test.ts exists, all tests pass
• npm run frontend:test passes
• npm run frontend:lint passes
• No changes to the source modules themselves

/kind cleanup /area testing /help