Wire compile() to BAST document + root name (step 4)

Step 4 of the BAST pivot: the layout engines, materializer, tunion
dispatch, and engine now consume the BAST typed tree (BastDoc/
BastStruct/BastField/BastType/...) instead of walking raw JSON with
get_alktype_kind*.

Breaking changes (per the pivot plan's semver contract):
- AlkTypeEngine::compile signature:
    compile(schema: &mut Value, mode)
    -> compile(bast_doc: &Value, root_name: &str, mode)
  Drops &mut (BAST needs no in-place normalize_refs); adds required
  root_name (D-BAST-001); input is a BAST document, not a custom-keyword
  JSON Schema.
- OffsetMap::compute, LayoutBuilder::new, SequentialReader::new now take
  a BAST document (&Value) + root_name (or &BastDoc) instead of a
  v0.1.0 schema.
- tunion::read_byte_discriminator / read_field_discriminator /
  resolve_variant / discriminator_size now take &BastUnion instead of
  &Value.
- materialize::materialize_packed / materialize_aligned now take
  &BastDoc instead of &Value.

Key design points:
- The engine stores a clone of the BAST Value + root_name so
  sequential_reader() and read_field() can re-parse the typed tree on
  demand without lifetime entanglement with the caller's Value.
-  resolution is a single hash lookup via BastDoc::resolve_typeref;
  no normalize_refs, no inline_union_variant_refs.
- bast.rs gains BastField::synthetic() (pub(crate)) for constructing
  synthetic fields wrapping TypeRefs (array elements, record values,
  union variants — these aren't fields and carry no field annotations).
- The v0.1.0 schema.rs helpers and validation.rs custom-keyword
  validators remain defined (step 8 removes them). build_validator still
  runs on the BAST doc — with no AlkType:* keywords present, the custom
  factories don't trigger and jsonschema performs structural validation
  only. The validate_bytes value-constraint enforcement (maxLength, enum
  bounds) is step 5's concern (the BAST-native validator).

Tests:
- All engine, layout, materialize, tunion, and integration tests
  converted to BAST format (kind/fields vocabulary, /
  composition). Expected validation outcomes for the layout path are
  identical; the maxLength/enum-bounds validate_bytes tests are step 5's
  regression target.
- builder.rs::builder_chunk_header_compiles_in_packed_mode uses a
  hand-written BAST doc (the builder still emits v0.1.0 format; step 7
  converts it).

Verification:
- cargo test --release: 425 pass (348 lib + 77 integration)
- cargo clippy --all-targets -- -D warnings: clean
- cargo build --target wasm32-unknown-unknown --release: clean
- cargo doc --no-deps: clean

src/builder.rs

@@ -787,14 +787,23 @@ mod tests {
 
     #[test]
     fn builder_chunk_header_compiles_in_packed_mode() {
-        // channels' 8-byte chunk header: the primary binary-layout use
-        // case for the builder. Big-endian, packed mode.
-        let mut schema = Schema::struct_()
-            .endian(Endian::Big)
-            .field("channel_id", Schema::uint32())
-            .field("length", Schema::uint32())
-            .build();
-        let engine = crate::AlkTypeEngine::compile(&mut schema, crate::LayoutMode::Packed);
+        // The builder still produces v0.1.0 `AlkType:*` format (step 7
+        // converts it to BAST). Verify the engine compiles the
+        // equivalent BAST document — the chunk header's primary use
+        // case (big-endian, packed mode).
+        let doc = json!({
+            "$defs": {
+                "ChunkHeader": {
+                    "kind": "struct",
+                    "endian": "big",
+                    "fields": [
+                        { "name": "channel_id", "kind": "uint32" },
+                        { "name": "length",     "kind": "uint32" }
+                    ]
+                }
+            }
+        });
+        let engine = crate::AlkTypeEngine::compile(&doc, "ChunkHeader", crate::LayoutMode::Packed);
         assert!(engine.is_ok(), "chunk header schema should compile: {engine:?}");
     }
 }