Fix BAST pivot: jsonschema remains a direct dependency

Correct the validator split section to clarify that jsonschema is
not removed — it remains the JSON Schema validator for both paths
(BAST meta-schema validation and standard JSON payload validation).
Only the custom keyword registration path is removed. Also fix the
build_validator and validate_json entries in the engine changes
table to reflect that they are repurposed, not removed.

docs/research/bast-pivot.md

@@ -586,9 +586,9 @@ aligned static mode (same as ADR-003):
 | `normalize_refs()` | Removed — BAST `$ref` values are always full JSON Pointers |
 | `inline_union_variant_refs()` | Removed — union mapping values are resolved lazily via `$ref` |
 | `parse_endian()`, `parse_align()`, `parse_encoding()`, `parse_discriminator()` | Adapted to read from BAST field/struct properties instead of keyword-value objects |
-| Custom keyword validators (19 `jsonschema::Keyword` impls) | Removed from alktype. BAST validation uses the BAST meta-schema + standard JSON Schema validator. Binary data validation uses `validate_bytes` (materialize + validate against a derived JSON Schema or the BAST structure directly). |
-| `build_validator()` | Repurposed or removed. The engine no longer registers custom keywords with `jsonschema`. |
-| `validate_json()` | May be removed or changed to validate against a separately-provided JSON Schema. |
+| Custom keyword validators (19 `jsonschema::Keyword` impls) | Removed. These were the only thing using `jsonschema`'s custom keyword API. |
+| `build_validator()` | Repurposed. Still builds a `jsonschema::Validator`, but from a standard JSON Schema (no custom keywords). Used for JSON payload validation (call's `OperationSpec` schemas, etc.) and for validating BAST documents against the BAST meta-schema. |
+| `validate_json()` | Unchanged in signature. Validates a `Value` against the engine's compiled `jsonschema::Validator` (now built from a standard JSON Schema instead of one with custom keywords). |
 | `validate_bytes()` | Unchanged in concept — materialize `Value` from bytes, then validate. The materialization step walks BAST instead of custom-keyword JSON. |
 
 ### Public API
@@ -614,7 +614,7 @@ aligned static mode (same as ADR-003):
 - `normalize_refs()` — BAST `$ref` values are always full JSON Pointers
 - `inline_union_variant_refs()` — union mapping values are resolved lazily
 - `get_alktype_kind()` / `get_alktype_kind_loose()` and their `_enum` variants — replaced by direct `kind` field parsing
-- The `jsonschema` crate dependency for custom keyword registration (the crate may remain as a transitive dependency for BAST meta-schema validation, but the engine no longer registers custom keywords with it)
+- Custom keyword registration with `jsonschema` — the engine no longer calls `jsonschema::options().with_keyword(...)`. The `jsonschema` crate **remains a direct dependency** for standard JSON Schema validation (validating JSON payloads like call's `OperationSpec` schemas, and validating BAST documents against the BAST meta-schema). The only thing removed is the custom keyword integration path.
 
 ### What is added
 
@@ -664,11 +664,11 @@ validation from the same JSON tree.
 └──────────┬───────────┘     └────────────┬─────────────┘
            │                              │
            ▼                              ▼
-  AlkTypeEngine::compile()      jsonschema::options()
+  AlkTypeEngine::compile()      build_validator(&json_schema)
            │                              │
            ▼                              ▼
-  Layout (offset map /          JSON Schema validator
-  layout builder)               (standard, no custom keywords)
+  Layout (offset map /          jsonschema::Validator
+  layout builder)               (standard JSON Schema)
            │                              │
            ▼                              ▼
   validate_bytes(&[u8])         validate_json(&Value)
@@ -679,6 +679,12 @@ describes binary layout. The JSON Schema document describes JSON data
 shape. They can be linked (a BAST struct can reference a JSON Schema by
 `$id` for validation) but they are separate documents.
 
+Both paths use `jsonschema` under the hood — the BAST path uses it to
+validate BAST documents against the BAST meta-schema at compile time;
+the JSON path uses it to validate JSON payloads against standard JSON
+Schema documents. The only thing removed is the custom keyword
+registration path (`jsonschema::options().with_keyword(...)`).
+
 ### What this means for consumers
 
 **alkcall** today uses alktype for two roles:
@@ -690,8 +696,10 @@ shape. They can be linked (a BAST struct can reference a JSON Schema by
 Under BAST:
 1. Binary layout — `AlkTypeEngine::compile(bast_doc, "ChunkHeader",
    Packed)` — same flow, different input format
-2. JSON validation — standard `jsonschema::options().build(&json_schema)`
-   — unchanged, but no longer goes through alktype's `build_validator()`
+2. JSON validation — `build_validator(&json_schema)` — same API,
+   now builds a standard `jsonschema::Validator` (no custom keywords).
+   Consumers that don't use binary at all (e.g., adapters around remote
+   JSON Schema APIs) use this path exclusively.
 
 The builder API can produce both formats:
 - `Schema::struct_().field(...).build()` → BAST JSON