Phase 11: real block textures for 2D tiles

Layers texture-averaged colors on top of palette.rs's hand-picked table as a
fallback (color_for_textured), not a hard replacement — biome-tinted/animated
blocks (grass top, leaves, water, lava) deliberately keep the hand-picked
color since averaging their raw jar textures would be wrong, not just
imprecise.

Vanilla: worker/src/textures.rs downloads Mojang's official client jar
directly from launchermeta/piston-meta/piston-data (same endpoints the real
launcher uses, gated behind ACCEPT_MINECRAFT_EULA=true, off by default,
mirrors BlueMap's accept-download) and averages every block texture, cached
to disk so it's not re-downloaded every restart.

Modded: ingests block_registry/block_textures messages from the mod (new
Postgres tables + MinIO storage in api/src/textures.ts) — sent once per
connection over the existing WS gateway.

texturepacks/<name>/ (Dynmap-style flat PNGs) lets an operator override the
vanilla defaults worker-wide via TEXTURE_PACK. A per-server texturePack
admin column/API exists for the same purpose, but render-time per-server
resolution (of both the admin selection and the ingested modded textures) is
explicitly deferred — the worker still applies one process-wide palette; true
per-server resolution needs the render pipeline to thread a server-scoped
palette through the batch/GPU-dispatch path, judged too big a change for this
phase. Documented in README.

Docker was unavailable in this dev environment for the usual integration-test
verification; bunx tsc --noEmit was used as a fallback static check instead
(clean except 2 pre-existing unrelated errors in markers.test.ts).

api/src/ws-gateway.ts

@@ -5,6 +5,7 @@ import { markChunkDirty } from "./redis";
 import { storeLinkCode } from "./link";
 import { recordAndPublishChat } from "./chat";
 import { arePlayerPositionsVisible, publishPlayerPositions, type PlayerPosition } from "./players";
+import { storeBlockRegistry, storeBlockTextures, type BlockRegistryEntry, type BlockTextureEntry } from "./textures";
 
 // Wire protocol (mod <-> api), one JSON object per WS text frame:
 //
@@ -58,6 +59,18 @@ import { arePlayerPositionsVisible, publishPlayerPositions, type PlayerPosition
 // players.ts's publishPlayerPositions to whatever browsers are subscribed on /ws/players/:serverId
 // (players-gateway.ts), gated on the per-server `playerPositionsVisible` admin toggle (independent
 // of the mod-local `playerTrackingEnabled` config that decides whether this message is sent at all).
+//
+//   mod -> api  {"type":"block_registry","entries":[{"id":4000,"name":"botania:manapool"}]}
+//   mod -> api  {"type":"block_textures","textures":[{"name":"botania:manapool","dataBase64":"..."}]}
+//
+// Phase 11: sent once after `hello_ack` (a world's numeric block-id assignments and mod-jar
+// contents are both stable for the server's lifetime, so there's no need to resend on a timer).
+// `block_registry` is the numeric-id -> registry-name mapping needed to make sense of
+// `chunkColumns.blockId`/`blockMeta` for modded blocks (see MCMapperMod.java's connect-time
+// registry dump); `block_textures` is the mod's best-effort classloader extraction of each
+// block's texture PNG (see textures.ts's doc comment for storage). Both are stored now but not
+// yet read by the render pipeline — see worker/README's Phase 11 note on the deferred per-server
+// palette-resolution work this unlocks.
 
 interface Column {
   x: number;
@@ -219,6 +232,18 @@ export const wsGateway = {
       await publishPlayerPositions(state.serverId, dimension, players);
       return;
     }
+
+    if (msg.type === "block_registry") {
+      const entries: BlockRegistryEntry[] = msg.entries ?? [];
+      await storeBlockRegistry(state.serverId, entries);
+      return;
+    }
+
+    if (msg.type === "block_textures") {
+      const textures: BlockTextureEntry[] = msg.textures ?? [];
+      await storeBlockTextures(state.serverId, textures);
+      return;
+    }
   },
 
   close(ws: any) {