Refactor/settings literal unions

[martinshub-tech]

this pr closes #440

Why
src/context/SettingsContext.tsx stored network, addressDisplay, autoDismiss, and themeMode as plain strings. This allowed typos and made it impossible for TypeScript to catch invalid values. The UI already restricts selections to a known set, so the type layer should reflect the same constraints.

What was changed
Literal‑union types
ts

export type NetworkOption = 'public' | 'test';
export type AddressDisplayOption = 'full' | 'short' | 'friendly';
export type AutoDismissOption = 'off' | '3s' | '5s' | '8s';
export type ThemeMode = 'light' | 'dark' | 'system';
Validation helpers (coerceNetwork, coerceAddressDisplay, coerceAutoDismiss, coerceTheme) that safely coerce any stored value to a valid enum, falling back to the default values from defaultPersistedSettings.
Applied coercion when building persistedSettings so corrupted or out‑of‑domain values are clamped to defaults.
Added VALID_THEMES array to support theme validation.
Extended SettingsPayload / SettingsState to use the new union types throughout the context and UI.
Updated default values and ensured the new types flow through the provider’s state, setters, and persistence logic.
Impact
Compile‑time safety for settings‑related code.
Runtime safety: malformed localStorage entries can no longer break the app; they are automatically replaced with sensible defaults.
No UI changes – the existing Settings UI continues to work unchanged.

[drips-wave]

@martinshub-tech Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits