theme: rebuild the code palette on measured contrast, not taste

The old palette had the hierarchy INVERTED. Measured against the background:
address grey58 = 6.0:1 and opcode bytes grey50 = 4.6:1, versus mnemonic cyan
3.8:1 and label yellow 4.3:1 — the structural noise you never read was louder
than the mnemonics and names that are the entire point. The pseudocode gutter
(grey37, 2.8:1) sat below the 3:1 accessibility floor. Half the colours were
terminal-palette names (cyan/yellow/white/greyNN), so the scheme rendered
differently on every user's terminal and could never match our hex theme. And
amber meant five different things (label, function header, data, member, match).

Principles now applied:
* frequency is inverse to intensity — mnemonics are on every line, so they get
  the brightest NEUTRAL rather than a hue; colour is spent on what you scan for
* one hue, one meaning — amber is attention/match and nothing else
* structure recedes: addresses/opcodes/gutters 3.2-3.9:1, never above body
* all hex, no terminal-palette names
* foreground encodes kind, background encodes state (match/cursor/link)
* never hue alone — bold/italic carries the same distinction for red-green
  colour-blind users

Result, all measured vs #12161c:
  mnemonic  #e8ecf2 15.3   body     #c3cad3 11.0   strings #9ece6a  9.9
  data/num  #d8a657  8.2   member   #93aee0  8.1   names   #7aa2f7  7.2
  comment   #7c8b9e  5.2   address  #6b7684  3.9   gutter  #626c7a  3.4
  opcodes   #5e6875  3.2
Signal band 7.2-15.3:1, structure band 3.2-3.9:1 — separated, nothing below 3:1,
and the old 2.8:1 gutter failure is fixed.

Verified by rendering a real listing: opcode bytes dimmest, addresses dim,
mnemonics brightest, names in blue. Suite 192/0.

Not touched: highlight.py maps Pygments tokens for the pseudocode view and still
uses its own colours — worth bringing into the same scheme next.

0 files changed, 0 insertions, 0 deletions