Add customizable band colors with local persistence and map legend editor; apply colors across map and DX views

[echo-gravitas]

This PR introduces a full user-customizable band color system and wires it into the existing UI. Requested in #358.

• Added a centralized band color module (src/utils/bandColors.js) with:
  • Default band palette
  • Frequency-to-band color resolution
  • LocalStorage persistence via openhamclock_bandColors
  • Change event broadcasting for live UI updates
• Refactored getBandColor() in src/utils/callsign.js to use the centralized color logic.
• Added a clickable band-color editor in the map legend (src/components/WorldMap.jsx):
  • Click a band chip to edit color
  • Save, reset single band, or reset all
  • Colors update immediately on map paths/markers
• Ensured changes propagate across the app (including DX Cluster) via a global color-change event trigger in src/App.jsx.
• Replaced hardcoded band legend colors in src/layouts/ClassicLayout.jsx with centralized band color lookups.
• Extended handling for frequency input units (MHz/kHz/Hz), so bands like 2m are correctly detected and colored.
• Expanded editable legend bands to include 2m and 70cm.
• Added openhamclock_bandColors to synced/snapshotted settings:
  • src/utils/config.js (settings sync keys)
  • src/utils/profiles.js (profile snapshot keys)
• Localized map legend labels for Sun/Moon in src/components/WorldMap.jsx and language files:
  • German: Sonne, Mond
  • English and all other languages: Sun, Moon

[denete]

The amount of changes in this PR with regard to quotation mark styles, formatting, etc. makes me feel that some developers are using auto formatting.

If we use autoformatting, what standards should we use? My preference is to commit a prettierrc to the codebase and allow it to be part of either the CI, part of the commit process (using githooks), or just as part of a developer's routine.

The goal with doing so is to limit the amount of 'cruft' that is found in a PR and to improve code review.

Thoughts?

[echo-gravitas]

@denete - Totally agree. The quotation/formatting churn in PRs is a strong signal we’re already auto-formatting, just inconsistently.

I’m actually already trying to move us in that direction in PR #402 by adding a standard .prettierrc and .editorconfig to the repo.

I’d strongly prefer we make formatting deterministic and shared across the team (rather than “whatever my IDE feels like today”). Without Prettier + EditorConfig, merges and reviews turn into unnecessary friction, and diffs become noisy.

In terms of enforcement: my vote is Prettier in CI (so it’s consistent and unavoidable), plus pre-commit / githooks (optional but recommended) to give fast feedback locally. That should drastically reduce cruft in PRs and make code review focus on logic instead of whitespace.

Cc @accius