Rebrand TypeDef to AlkType in code, keyword strings, and docs

Rename all 19 JSON Schema custom keyword strings from "TypeDef:*"
to "AlkType:*" (e.g., "TypeDef:Struct" -> "AlkType:Struct")
across source, tests, and docs. This is a breaking change to the
schema format itself — existing schemas using the old keywords
must be updated.

Rename the Rust identifiers:
- TypedefEngine -> AlkTypeEngine
- TypedefError -> AlkTypeError
- TypeDefKind -> AlkTypeKind
- TYPEDEF_PREFIX -> ALKTYPE_PREFIX
- get_typedef_kind{,_loose,_loose_enum,_enum} ->
  get_alktype_kind{,_loose,_loose_enum,_enum}

Update error message strings ("unknown TypeDef kind" ->
"unknown AlkType kind"), 11 test function names containing
typedef_kind/to_typedef_error, and doc-comment prose ("TypeDef
kind" -> "AlkType kind", "typedef engine" -> "alktype
engine", "typedef schema" -> "alktype schema"). Fix the broken
docs/architecture/crates/typedef/ path references in source doc
comments to point at docs/architecture/ directly. Rebrand the
typedef:annotation test fixture and the "not-a-typedef" test
string to their alktype equivalents.

Update ~20 generic "typedef" prose references in the architecture
docs ("typedef is the binary struct engine", "use typedef",
"typedef limitation", "replaced by typedef", etc.) to alktype.
Rename TypedefEngine in the ADR-007 code example to AlkTypeEngine.

Preserve as provenance per the prior prose-rebrand decision:
typedef.ts references (external TypeBox source file),
docs/research/alknet-typedef/findings.md research citations,
/workspace/alknet-typedef-poc/ POC path, and the
"alknet-typedef:" research section headers in findings.

Build, 295 tests, and clippy all pass clean.

docs/architecture/validation.md

@@ -5,22 +5,22 @@ last_updated: 2026-07-22
 
 # alktype — Validation
 
-The validation layer: custom keyword validators for all 19 `TypeDef:*`
-kinds, the `TypedefError` enum, load-time vs access-time validation
-strategy, and the `TypedefEngine` as the compiled form of a schema.
+The validation layer: custom keyword validators for all 19 `AlkType:*`
+kinds, the `AlkTypeError` enum, load-time vs access-time validation
+strategy, and the `AlkTypeEngine` as the compiled form of a schema.
 
 ## Validation Strategy
 
 Validation is delegated to the `jsonschema` crate (v0.46.5, Draft
-2020-12). The typedef engine does not implement its own validation —
-it registers custom keyword validators for each `TypeDef:*` kind and
+2020-12). The alktype engine does not implement its own validation —
+it registers custom keyword validators for each `AlkType:*` kind and
 lets `jsonschema` handle the structural validation (object properties,
 required fields, array items, enum values).
 
 The strategy is decided in [ADR-004](decisions/004-error-handling-validation-strategy.md):
 
 1. **Load time:** Parse the schema JSON, build the layout engine, build the
-   jsonschema validator. This is the `TypedefEngine::compile(schema)` constructor.
+   jsonschema validator. This is the `AlkTypeEngine::compile(schema)` constructor.
 2. **Access time:** Use the compiled engine for repeated read/write
    operations. Validation is opt-in per operation.
 
@@ -37,7 +37,7 @@ the correct separation of concerns:
 - **Binary access validation** (data access layer): the read/write
   functions perform type-level validation at access time — range checks
   for integers, UTF-8 validity for strings, buffer bounds checking.
-  These return `TypedefError::Access` with field paths.
+  These return `AlkTypeError::Access` with field paths.
 
 The "schema is the format" principle means the same schema describes
 both the JSON shape and the binary layout. The jsonschema validator
@@ -47,13 +47,13 @@ buffer into a `Value` tree via the data access layer, then validates
 that `Value` against the jsonschema validator. This is a two-step
 process, not a single `validate(buffer)` call.
 
-### The `TypedefEngine` struct
+### The `AlkTypeEngine` struct
 
-The `TypedefEngine` is the compiled form of a schema. It supports both
+The `AlkTypeEngine` is the compiled form of a schema. It supports both
 layout modes (ADR-002) via an internal `Layout` enum:
 
 ```rust
-pub struct TypedefEngine {
+pub struct AlkTypeEngine {
     layout: Layout,                   // packed or aligned (private enum)
     validator: jsonschema::Validator, // compiled once at load time
     endian: Endian,                   // parsed from the schema's "endian" annotation
@@ -72,8 +72,8 @@ The consumer selects the mode at construction time via `LayoutMode`
 enum is private — the engine exposes mode-appropriate accessors instead:
 
 ```rust
-impl TypedefEngine {
-    pub fn compile(schema: &mut Value, mode: LayoutMode) -> Result<Self, TypedefError>;
+impl AlkTypeEngine {
+    pub fn compile(schema: &mut Value, mode: LayoutMode) -> Result<Self, AlkTypeError>;
     pub fn mode(&self) -> LayoutMode;
     pub fn endian(&self) -> Endian;
     pub fn offset_map(&self) -> Option<&OffsetMap>;          // Some in aligned mode
@@ -94,39 +94,39 @@ The `SequentialReader` (read-side) is not stored — it has mutable cursor
 state that the consumer owns, so `sequential_reader()` constructs a fresh
 reader on each call (ADR-007).
 
-The `read_field`/`write_field` methods on `TypedefEngine` are the
+The `read_field`/`write_field` methods on `AlkTypeEngine` are the
 aligned-mode data-access API — see [data-access.md](data-access.md)
 §"Higher-level read/write".
 
 ## Custom Keyword Validators
 
-Each `TypeDef:*` kind gets a `Keyword` implementation registered via
+Each `AlkType:*` kind gets a `Keyword` implementation registered via
 `jsonschema::options().with_keyword(...)`. The validators check leaf
 type constraints; `jsonschema` handles all structural validation.
 
 ### Numeric type validators
 
-**`TypeDef:Float32` / `TypeDef:Float64`:**
+**`AlkType:Float32` / `AlkType:Float64`:**
 - Value must be a finite number.
 - For `Float32`: value must be representable as `f32` (no precision loss
   beyond `f32`'s mantissa).
 
-**`TypeDef:Int8` / `TypeDef:Int16` / `TypeDef:Int32`:**
+**`AlkType:Int8` / `AlkType:Int16` / `AlkType:Int32`:**
 - Value must be an integer within the type's range.
 - Int8: -128..127, Int16: -32768..32767, Int32: -2147483648..2147483647.
 
-**`TypeDef:Uint8` / `TypeDef:Uint16` / `TypeDef:Uint32`:**
+**`AlkType:Uint8` / `AlkType:Uint16` / `AlkType:Uint32`:**
 - Value must be a non-negative integer within the type's range.
 - Uint8: 0..255, Uint16: 0..65535, Uint32: 0..4294967295.
 
 ### String and binary validators
 
-**`TypeDef:String`:**
+**`AlkType:String`:**
 - Value must be a valid UTF-8 string.
 - If `maxLength` is specified in the schema, the string's byte length
   must not exceed it.
 
-**`TypeDef:Bytes`:**
+**`AlkType:Bytes`:**
 - Value must be a string (JSON represents binary data as a string — JSON
   has no native byte type).
 - If `maxLength` is specified, the byte length must not exceed it.
@@ -135,34 +135,34 @@ type constraints; `jsonschema` handles all structural validation.
   validation) uses a string; the binary representation (for data access)
   uses `&[u8]` directly.
 
-**`TypeDef:Enum`:**
-- The `TypeDef:Enum` custom keyword signals that the type is an enum for
+**`AlkType:Enum`:**
+- The `AlkType:Enum` custom keyword signals that the type is an enum for
   *layout* purposes (the engine needs to know it's a fixed-size u32 index,
   not a variable-length string). The built-in `enum` keyword provides the
   value list and handles value-membership validation. The custom keyword
   validator is a no-op beyond the built-in check — it exists solely for
   the layout engine to recognize the type.
 
-**`TypeDef:Timestamp`:**
+**`AlkType:Timestamp`:**
 - Value must be a valid RFC 3339 timestamp string (the internet profile
   of ISO 8601, e.g., `"2026-07-20T15:30:00Z"`).
 
 ### Composite type validators
 
-**`TypeDef:Struct`:**
+**`AlkType:Struct`:**
 - Value must be an object.
-- Each property must match its declared `TypeDef:*` kind.
+- Each property must match its declared `AlkType:*` kind.
 - Required fields must be present.
 - The `jsonschema` crate's built-in `properties` and `required` keywords
   handle the structural checks — the custom keyword only needs to
-  validate that each field's value matches its `TypeDef:*` kind.
+  validate that each field's value matches its `AlkType:*` kind.
 
-**`TypeDef:Union`:**
+**`AlkType:Union`:**
 - The discriminator value must be one of the mapping keys.
 - The variant struct must match the declared schema for that discriminator
   value.
 
-**`TypeDef:Array`:**
+**`AlkType:Array`:**
 - Value must be an array.
 - Each element must match the array's declared element type.
 - If `minItems`/`maxItems` is specified, the array length must be within
@@ -170,19 +170,19 @@ type constraints; `jsonschema` handles all structural validation.
 
 ### Other validators
 
-**`TypeDef:Boolean`:**
+**`AlkType:Boolean`:**
 - Value must be `true` or `false`.
 
-**`TypeDef:Record`:**
+**`AlkType:Record`:**
 - Value must be an object.
 - All values must match the record's declared value type (specified via
   the `"values"` property in the schema, e.g.,
-  `"values": { "TypeDef:Float32": true }`).
+  `"values": { "AlkType:Float32": true }`).
 
 ### Validator implementation pattern
 
 Each custom keyword implementation is ~10 lines. Example for
-`TypeDef:Float32`:
+`AlkType:Float32`:
 
 ```rust
 struct Float32Validator;
@@ -204,7 +204,7 @@ Registration:
 
 ```rust
 let validator = jsonschema::options()
-    .with_keyword("TypeDef:Float32", |parent, value, path| {
+    .with_keyword("AlkType:Float32", |parent, value, path| {
         Ok(Box::new(Float32Validator))
     })
     .build(&schema)?;
@@ -212,18 +212,18 @@ let validator = jsonschema::options()
 
 The factory closure receives the parent schema object, the keyword's
 value, and the schema path. This enables cross-keyword awareness — for
-example, a `TypeDef:Struct` validator can inspect the parent's
-`properties` to validate each field against its declared `TypeDef:*` kind.
+example, a `AlkType:Struct` validator can inspect the parent's
+`properties` to validate each field against its declared `AlkType:*` kind.
 
-## TypedefError
+## AlkTypeError
 
-A single `TypedefError` enum covers all error conditions across the
+A single `AlkTypeError` enum covers all error conditions across the
 engine's three phases (schema parsing, offset computation, read/write)
 plus validation. Decided in [ADR-004](decisions/004-error-handling-validation-strategy.md).
 
 ```rust
-pub enum TypedefError {
-    /// Schema parsing errors (invalid JSON, missing keywords, unknown TypeDef kinds).
+pub enum AlkTypeError {
+    /// Schema parsing errors (invalid JSON, missing keywords, unknown AlkType kinds).
     Schema(String),
     /// Offset computation errors (field not found, unsupported type).
     Offset { field_path: String, reason: String },
@@ -234,8 +234,8 @@ pub enum TypedefError {
 }
 ```
 
-- **`Schema`** — for errors during `TypedefEngine::compile()`. Invalid
-  JSON, missing required keywords, unknown `TypeDef:*` kinds.
+- **`Schema`** — for errors during `AlkTypeEngine::compile()`. Invalid
+  JSON, missing required keywords, unknown `AlkType:*` kinds.
 - **`Offset`** — for errors during offset computation. Field not found
   in the schema, type not supported for offset computation, recursive
   depth exceeded. Carries the field path.
@@ -244,14 +244,14 @@ pub enum TypedefError {
   Carries the field path.
 - **`Validation`** — wraps `jsonschema`'s `ValidationError`. The
   `'static` lifetime is correct — the validator owns its schema reference
-  and lives for the lifetime of the `TypedefEngine`.
+  and lives for the lifetime of the `AlkTypeEngine`.
 
 ### Field-path-carrying errors
 
 Read/write and offset errors include the field path for debugging:
 
 ```rust
-Err(TypedefError::Access {
+Err(AlkTypeError::Access {
     field_path: "header.version".to_string(),
     reason: "buffer too short: need 4 bytes at offset 12, have 2".to_string(),
 })
@@ -262,7 +262,7 @@ you exactly which field failed and why.
 
 ## Validation Timing
 
-### Load time: `TypedefEngine::compile()`
+### Load time: `AlkTypeEngine::compile()`
 
 The expensive work happens once at schema load time:
 1. Normalize `$ref` values in the schema (`normalize_refs`).
@@ -270,7 +270,7 @@ The expensive work happens once at schema load time:
 3. Compute the layout (`LayoutBuilder`/`SequentialReader` for packed, `OffsetMap` for aligned).
 4. Build the jsonschema validator (`jsonschema::options().with_keyword(...).build(&schema)?`).
 
-The result is a `TypedefEngine` that can be used for repeated operations.
+The result is a `AlkTypeEngine` that can be used for repeated operations.
 
 ### Access time: `engine.validate_json(&Value)` / `engine.is_valid_json(&Value)`
 
@@ -281,7 +281,7 @@ validator is already compiled — these are fast checks against the
 compiled validator.
 
 ```rust
-pub fn validate_json(&self, instance: &Value) -> Result<(), TypedefError>;
+pub fn validate_json(&self, instance: &Value) -> Result<(), AlkTypeError>;
 pub fn is_valid_json(&self, instance: &Value) -> bool;
 ```
 
@@ -314,12 +314,12 @@ representation first, then access the binary buffer.
 
 | Decision | ADR | Summary |
 |----------|-----|---------|
-| Error handling and validation | [ADR-004](decisions/004-error-handling-validation-strategy.md) | `TypedefError` enum; load-time build, access-time check; field-path-carrying errors; jsonschema `ValidationError` wrapping |
+| Error handling and validation | [ADR-004](decisions/004-error-handling-validation-strategy.md) | `AlkTypeError` enum; load-time build, access-time check; field-path-carrying errors; jsonschema `ValidationError` wrapping |
 | Purpose and scope | [ADR-001](decisions/001-alktype-purpose-scope-jsonschema-engine.md) | Why jsonschema not a custom engine |
 
 ## Open Questions
 
-None specific to validation. The three typedef OQs (OQ-001, OQ-002,
+None specific to validation. The three alktype OQs (OQ-001, OQ-002,
 OQ-003) are about layout, platform support, and schema construction —
 not validation.
 
@@ -329,7 +329,7 @@ not validation.
   custom keyword validators for all 17 kinds
 - [ADR-004](decisions/004-error-handling-validation-strategy.md) —
   error handling and validation strategy
-- [schema-layer.md](schema-layer.md) — the 17 TypeDef kinds that the
+- [schema-layer.md](schema-layer.md) — the 17 AlkType kinds that the
   validators check
 - [data-access.md](data-access.md) — read/write functions that operate
   on the same buffers