Let a caller say which end of a hex string holds alpha

[smelfungus]

Hex here follows android.graphics.Color: alpha first, so a string pasted out of a stylesheet is read backwards. #FF000080 is a half-transparent red to CSS and an opaque navy here, and #3380CCFF, an opaque blue, arrives as a pale one at a fifth opacity. Neither fails — they parse, and come back a different colour. The library publishes a wasmJs target, so that is a string a caller can reasonably be holding.

Eight hex digits cannot say which convention wrote them, so there is nothing to detect and the ambiguity is named instead. HexAlpha.First stays the default and no existing string changes meaning; Last reads and writes the CSS order. Four digits parse now rather than being rejected, in whichever order was asked for, which is what #RGBA needed.

HexAlpha.None replaces the includeAlpha flag rather than sitting beside it. A boolean and a position together describe four states where there are three, and the fourth — no alpha, at the end — says nothing. Parsing with None accepts only the three and six digit forms: a caller who asks for a colour without alpha and is handed one with it should get null rather than a quiet reinterpretation.

Callers passing includeAlpha will not compile until they name a HexAlpha. That is the intended trade: the old spelling has no meaning under the new one, and a compile error is the right way to find out. The four functions' JVM signatures move with it, so anything linked against the old binaries needs recompiling too.