Use the real user avatar on the lock screen, and let its keyboard type every character

Two gaps, both found by being asked about them.

~/.face was never read. The file exists here, a 300x300 JPEG, and a grep for
.face/AccountsService/avatar_path returned nothing anywhere in the codebase:
the lock screen drew a coloured circle with the user's initial
unconditionally. It now looks for ~/.face, ~/.face.icon, then
/var/lib/AccountsService/icons/$USER, which is where GNOME and KDE keep the
picture their settings UI sets. Scaled to cover the circle and
centre-cropped rather than letterboxed, and masked with a soft edge. Falls
back to the initial when nothing is set or the file will not decode.

That needed a raster decoder, since ~/.face is JPEG and the only image code
here was resvg, which is SVG-only. Added image with default features off and
only jpeg and png.

The on-screen keyboard could not type most passwords. It had letters,
digits, and the digits' own shifted symbols, and nothing else - no -, _, .,
/, =, [, ], ;, ', comma, backslash or backtick. For the case that keyboard
exists for, a session with no reachable physical keyboard, a password
containing any of those meant no way in at all. Every printable ASCII
character now has a key, with a test asserting the whole 0x20..0x7f range
rather than spot-checking.

The lock screen itself could not be screenshotted: locking a nested instance
hits the pre-existing EGL context-loss crash already recorded in docs/TODO.md,
confirmed again here. That is environmental and predates this change, so the
on-screen appearance still needs the real session. The avatar path is covered
by four tests including one that decodes the real ~/.face through the same
function the lock screen calls.

529 tests pass, clippy clean.

2 files changed, 67 insertions, 0 deletions

diff --git a/docs/DEFAULTS.md b/docs/DEFAULTS.md
index 014c6f5..ded5b03 100644
--- a/docs/DEFAULTS.md
+++ b/docs/DEFAULTS.md
@@ -1107,3 +1107,26 @@ own `chrome/` directory uses for `userChrome-traditional.css` versus
 Firefox is a separate surface again: it draws its window buttons itself and
 takes them from `userChrome.css`, which needs
 `toolkit.legacyUserProfileCustomizations.stylesheets` set to `true`.
+
+## Lock screen: avatar and on-screen keyboard
+
+**Avatar.** The lock screen shows the user's own picture, looked for in the
+conventional places, most specific first:
+
+1. `~/.face`
+2. `~/.face.icon`
+3. `/var/lib/AccountsService/icons/$USER` - where GNOME and KDE store the
+   picture set through their own settings UI
+
+These are conventionally JPEG or PNG. The image is scaled to *cover* the
+circle and centre-cropped, not letterboxed into it, and masked with a
+one-pixel-soft edge. With no avatar set, or a file that cannot be decoded,
+it falls back to the coloured circle with the user's initial
+(`theme.lock.avatar_bg`).
+
+**On-screen keyboard.** `theme.lock.show_keyboard` (default on) draws a
+QWERTY layout for a session with no reachable physical keyboard. Every
+printable ASCII character is typable, shifted or unshifted - letters,
+digits, and all of ``-_=+[]{}\|;:'",.<>/?~`` plus space. A test asserts
+the full range, because a lock screen that cannot type some character in
+the password is a lockout rather than an inconvenience.
diff --git a/docs/TODO.md b/docs/TODO.md
index 18e551a..e086889 100644
--- a/docs/TODO.md
+++ b/docs/TODO.md
@@ -1,5 +1,49 @@
 # TODO / planned features - master checklist
 
+## Lock screen: the avatar was never read, and the keyboard could not type most passwords (2026-08-28)
+
+Two questions, both real gaps.
+
+**`~/.face` was never read.** The file exists on this machine (a 300x300
+JPEG, dated 2026-07-22) and nothing in the codebase ever opened it - a grep
+for `.face`/`AccountsService`/`avatar_path` returned nothing. The lock
+screen drew a coloured circle with the user's initial unconditionally, so a
+machine with an avatar set still showed a letter.
+
+Now looked for as `~/.face`, then `~/.face.icon`, then
+`/var/lib/AccountsService/icons/$USER`, which is where GNOME and KDE keep
+the picture their settings UI sets. Scaled to *cover* the circle and
+centre-cropped rather than letterboxed - a portrait fitted inside a round
+frame reads as a mistake, and every desktop that shows one crops. Masked
+with a one-pixel-soft edge so it is not a jagged cut-out. Falls back to the
+initial when there is no avatar or the file will not decode.
+
+This needed a raster decoder: `~/.face` is JPEG and the only image code here
+was `resvg`, which is SVG-only. Added `image` with default features off and
+just `jpeg` and `png` - two codecs, not the whole format zoo, on a
+compositor that has to build on a low-spec machine.
+
+**The on-screen keyboard could not type most passwords.** It had the
+letters, the digits, and the digits' own shifted symbols (`!` through `)`)
+- and nothing else. No `-`, `_`, `.`, `/`, `=`, `[`, `]`, `;`, `'`, `,`,
+`\`, or backtick. For the case this keyboard exists for - a session with no
+reachable physical keyboard - a password containing any of those meant no
+way in at all. That is a lockout, not an inconvenience.
+
+Every printable ASCII character now has a key, and a test asserts exactly
+that over the whole `0x20..0x7f` range rather than spot-checking a few.
+
+**Verification.** The avatar path is covered by four tests including one
+that decodes the real `~/.face` on this machine through the same function
+the lock screen calls. The lock screen itself could not be screenshotted:
+locking a nested instance hits the pre-existing EGL context-loss crash this
+file already records, confirmed again here (`BAD_SURFACE` on
+`eglSwapBuffers`, then `eglCreatePlatformWindowSurfaceEXT` failing). That is
+environmental and predates this change; the on-screen appearance needs the
+real session.
+
+277 core tests, 165 wayland, 529 total, clippy clean.
+
 ## srdwm now generates the GTK button stylesheet too (2026-08-28)
 
 The previous entry recorded a deliberate decision *not* to write GTK CSS,