max / alloy

Fix which ANSI slots the greeter names The tuigreet --theme string had `time` and `action` at dark_gray, which is slot 8 and content.muted, drawn onto the console background at slot 0. Slot 0 is the darkest tone in either polarity, so that is muted grey on near-black: a contrast ratio under 2:1, and it left the clock and the F-key hints all but invisible on the first screen of a boot. The cause is that the screen has two surfaces and the string was written as if it had one. tuigreet paints a background for exactly one element, the login card (`container`); the clock above it and the status line below it sit directly on the console. So elements outside the card have to name a light tone and elements inside it a dark one, and getting that backwards is invisible when you write the string and obvious the moment it draws. `time` and `action` move to white (slot 15, surface.overlay). `container` moves from white to gray, which is slot 7 and is what skelgen's achromatic table calls the login card, so the card reads as a raised surface rather than as the lightest tone available. `prompt` and `button` move from yellow to light_red: yellow is slot 3, status.warning, which does not belong on a prompt, and it sat under 3:1 on the card where the accent at slot 9 clears 5:1. Every slot named is achromatic or the accent, so the whole string inverts with the theme and reads the same way against the night table. `title` follows `border` in tuigreet and `greet` follows `text`, so neither needs naming. The doc had the same mistake in a different form: it said tuigreet asks for `white` and gets `surface.page`, which is two errors, since white is slot 15 and carries surface.overlay. ratatui's numbering is what tuigreet inherits by handing each value to `Color::from_str`, and there gray is 7 and white is 15, not the other way around.