feat(color): expand the palette to 64 tiered slots, with a colors example

[dsent]

What

• expand Color from 16 to 64 slots, in four tiers of sixteen
• add 24 hues with name constants: orange, brown, tan, yellowgreen, skyblue, purple, pink, gray, coral, gold, limegreen, springgreen, turquoise, azure, slateblue, crimson, khaki, salmon, mint, powderblue, lavender, orchid, royalblue, slategray
• widen Color.valid from c < 16 to c < 64
• make __index gate on Color.valid, so every index it rejects returns nil
• correct the legacy hex comments, which claimed #bf01bf for magenta and #01bf01 for green where the values are #BF00BF and #00BF00
• add a colors example that prints the whole palette and paints a picture using only named colors

Why

Eight hues is a thin box of pencils. Children reach for orange, brown, pink and purple immediately, and there was no way to name any of them — a drawing program either settled for the wrong color or dropped to raw RGB, which is exactly what Color exists to avoid.

The tiers are ordered by how much they earn their place, so the palette can be cut at any 16-slot boundary without losing expressiveness:

Slots	What lives there
0-15	the existing eight, unchanged
16-31	the everyday extras a pencil box has
32-47	hues that even out the color wheel
48-63	soft pastels, droppable

How it works

One rule covers all 64 slots. The palette is 32 vivid colors; each sits in a bright slot, and the normal slot below it is that color at 0.75 strength. That is already how 0-15 was built — bright was 1 and plain was 0.75 — so the change generalizes the existing scheme rather than bolting a second one beside it.

A bare name still resolves to the normal slot, as Color.red always has; + Color.bright selects the vivid one. Lazy computation and caching in __index are unchanged.

Naming follows CSS except where the pencil-box meaning differs. brown is #964B00: CSS brown is #A52A2A, which is hue 0 and reads as brick red on the device.

Compatibility

Indices 0-15 keep their values byte for byte, and the 8 existing name constants are untouched. Indices 16-63 were rejected by Color.valid before this change, so nothing correct depended on them.

One behavior change worth stating plainly: Color[n] is now nil for any index Color.valid rejects — negative, fractional, 64 and up, and non-numbers. Previously those fell through to the bit decomposition and came back as a recycled-bit color; Color[-1] returned a gray. Color.valid rejected them before and after, so no correct program is affected, but a program misusing an index now fails on nil at gfx.setColor instead of quietly drawing something wrong.

The example

src/examples/colors has two screens, toggled with Space: every slot with its number and name, and a picture drawn entirely from named colors. Its README teaches the one idea a child needs — a color name is a number, so Color.red + Color.bright is just 2 + 8.

Validation

• full suite under LuaJIT: 686 successes, 0 failures, 0 errors — identical to the count on unmodified dev
• all 64 slots return four channels in 0..1; all 32 vivid slots match their intended hex; every normal slot is its vivid slot at 0.75 strength; all 32 names map to a normal slot; 0-15 reproduce the legacy bit formula byte for byte; the nine rejected index forms all yield nil — 662 assertions, 0 failures. The same assertions run against unmodified dev fail 131 times, so they are not vacuous.
• rendered every slot on a real Compy and sampled the screenshot: 64/64 pixel-exact against the intended palette. The same program on a build without this change renders 16-63 wrong.
• just zip-examples-all packages colors.compy alongside the existing examples

[dsent]

Screens from the new example program, displaying the full palette.