fix(imaging): normalise avatar figures before building URLs

Legacy accounts can carry a malformed stored look — the old register default
`hr-100-.hd-180-1...` has an empty colour slot — which the imager rejects with
400 "Invalid figure format", so the avatar renders broken everywhere the look
appears. Normalise the figure in the shared URL builder (`getAvatarUrl`, used by
every avatar on the site): an unrenderable look becomes `DEFAULT_AVATAR_FIGURE`
while the proxy route keeps rejecting malformed input with 400.

The rule set and default now live in one client-safe module
(`src/lib/avatar-figure.ts`), shared by the URL builder and the server parser.

src/lib/imager-upstream.ts

@@ -1,5 +1,10 @@
 import "server-only";
 
+import {
+	AVATAR_FIGURE_MAX_LEN as FIGURE_MAX_LEN,
+	AVATAR_FIGURE_MAX_PARTS as FIGURE_MAX_PARTS,
+	AVATAR_FIGURE_RE as FIGURE_RE,
+} from "@/lib/avatar-figure";
 import {
 	avatarCacheDir,
 	imagingCacheKey,
@@ -9,13 +14,9 @@ import {
 import { resolveImagerBase } from "@/lib/runtime-asset-config";
 
 // The client's figure strings are passed straight through to the imager, which
-// is the authority on what it can draw. Only the first segment is required to
-// look like a real part (`hd-180`); the rest is deliberately loose because some
-// clients append extra segments (e.g. a trailing `.0`) that the renderer still
-// accepts. Over-strict validation here turned valid avatars into 400s.
-export const FIGURE_RE = /^[a-z]{2}-\d+(?:[.-][a-z0-9]+)*$/i;
-export const FIGURE_MAX_LEN = 512;
-export const FIGURE_MAX_PARTS = 24;
+// is the authority on what it can draw. The rules live in `avatar-figure.ts` so
+// the URL builder applies the exact same ones; the parser only enforces them.
+export { FIGURE_MAX_LEN, FIGURE_MAX_PARTS, FIGURE_RE };
 
 const HABBO_PUBLIC_UPSTREAM = "https://www.habbo.com/habbo-imaging/avatarimage";