Phase 13: forge-1_12_2 ships blockstate/model JSON for non-cube models

BlockAssetExtractor#extractModels walks every active mod's own
jar/directory (Loader#getActiveModList's ModContainer#getSource, not
the classloader, since directory listing isn't a classloader
operation) for every blockstates/*.json and models/block/**/*.json
file, shipping all of them over a new batched block_models WS message
alongside the existing Phase 11 block_registry/block_textures dump.
Resolution of this data into real non-cube geometry is entirely
backend-side (see MCMapper-Backend's worker/src/models.rs).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015tKdPZt78zbPUZMXWzKEKt

README.md

@@ -129,6 +129,31 @@ matching this phase's Enigmatica-2-focused scope. See MCMapper-Backend's README
 backend currently does with this data (short version: stores it; per-server render-time
 resolution is explicitly deferred, documented there).
 
+### Real (non-cube) block models (Phase 13)
+
+`BlockAssetExtractor#extractModels` ships every `assets/<modid>/blockstates/*.json` (flat, matching
+vanilla's own layout — no subfolders expected) and `assets/<modid>/models/block/**/*.json`
+(recursive — mods are free to nest these, e.g. a shared `models/block/base/` folder) file for every
+currently-active mod, keyed the way MCMapper-Backend's `worker/src/models.rs` expects. Unlike
+`extractTextures`, this can't use the classloader (there's no `ClassLoader` API to list a
+directory's contents, only to read one known file by path) — it walks each mod's own source
+instead, via `net.minecraftforge.fml.common.Loader#getActiveModList`'s `ModContainer#getSource`,
+handling both shapes that can show up there: a packed jar (opened as a `ZipFile`) in production, or
+a raw exploded directory when running from an IDE/dev environment.
+
+The mod deliberately ships **every** model file it finds under a mod's `models/block/` tree rather
+than trying to work out which ones a given blockstate actually references — a blockstate's
+`"model"` field (or another model's `"parent"`) can point at a path that doesn't match the
+referencing block's own registry path 1:1 (e.g. several blocks sharing one base model), and the
+mod has no JSON parser to resolve that itself. That resolution — parent-chain walking, texture-
+variable substitution, picking a representative variant — is entirely backend-side (see
+MCMapper-Backend's README's own Phase 13 section for what it does and doesn't handle, e.g. no
+`multipart` blockstate support, no property-based variant selection).
+
+Sent as a new `block_models` WS message, batched 50/message like `block_textures`, from the same
+ready-listener callback as the Phase 11 registry/texture dump. Verified via a real
+`./gradlew :forge-1_12_2:compileJava` against the pinned legacy ForgeGradle toolchain.
+
 ## Attribution
 
 See `THIRD_PARTY_NOTICES.md`.