Yesterday's PR #3110 darkening-workaround flow had me dropping a
hand-fixed "Default Dark.json" into ~/.config/AetherSDR/themes/ to
bypass the Qt resource rebuild.  That file stuck around, and because
ThemeManager::scanAvailableThemes() runs the user-dir scan after the
built-in scan with an unconditional `m_themePaths.insert(name, full)`,
the stale user-dir copy SHADOWED the bundled :/themes/default-dark.json.

The stale copy predated PR #3122's waterfall-colormap restructure
(flat single gradient → nested object with 5 named schemes).  After it
loaded:

  * color.waterfall.colormap = ThemeGradient (single, the old flat shape)
  * color.waterfall.colormap.{default,grayscale,blueGreen,fire,plasma}
      = MISSING from m_tokens

The SpectrumWidget cache rebuild fell back to the black→white grayscale
ramp for all 5 schemes — the dropdown still listed them but every
selection rendered identical greyscale, which is exactly the symptom
Jeremy reported.

This commit:

  * Treats built-in names (paths starting with `:/themes/`) as
    RESERVED.  A user-dir file with the same `name` field is logged
    with a clear warning and skipped, so the bundled version wins.
  * Comment documents the failure mode + points readers at "Save As
    under a new name" as the correct workflow for tweaked themes.

The stale file itself was deleted out-of-band — this commit prevents
the symptom from recurring on any other developer / user who happens
to have an old user-dir Default Dark.json sitting around (anyone who
followed yesterday's workaround in particular).

Save As in the Theme Editor was already disallowing same-name
overwrites via QMessageBox, so the editor itself can't manufacture
this state.  This guard catches the manual / migration case.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…base hex (aethersdr#3110)

Post-aethersdr#3102 user testing surfaced visible darkening of applet
backgrounds, title bar, and status bar.  Root cause: my canonical
taxonomy picked design-aesthetic values for two of the highest-impact
tokens instead of the actual dominant codebase hex:

  color.background.0  was #0a0e14  →  now #0f0f1a
                      (84 refs to literal #0f0f1a — the QWidget base
                      colour in Theme.h's app-wide stylesheet; the
                      old token value was ΔRGB 12 darker, perceptible
                      against dark UI)

  color.text.primary  was #e6f0fa  →  now #c8d8e8
                      (367 refs — the most-used colour in the whole
                      codebase by far; the old token value was visibly
                      lighter)

Both files updated in lockstep:
  - resources/themes/default-dark.json (v1.2 → v1.3, baked into the
    Qt resource bundle)
  - src/core/ThemeManager.cpp::seedBuiltinDefaults() (the compiled-in
    fallback when no theme file loads)

No call-site changes needed — every site that resolves through
ThemeManager::color() or the {{color.text.primary}} /
{{color.background.0}}
template placeholders automatically picks up the new values.

Lesson for the taxonomy doc: canonical token values must come from
the **dominant codebase hex** at sites that use the token, not from
the designer's first instinct.  Phase 4 Light theme can revisit the
aesthetic tuning; Phase 2's job is bit-identical-where-possible
preservation of the v26.5.3 look.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>