std.schema: nested records + arrays (recursive value model, JSON-tree input)

[paul-hammant]

Summary

std.schema validates a flat string → string map today. Real-world data is
often nested (objects-within-objects, arrays). Add nested records and arrays:

schema.record() {
    schema.field("name", schema.STR) { schema.present() }
    schema.field("address", schema.record()) {     // nested record
        schema.field("city", schema.STR) { schema.present() }
        schema.field("zip", schema.STR)  { schema.pattern("...") }
    }
    schema.field("tags", schema.array(schema.STR)) { schema.min(1) }  // array
}

Why it's deferred (from the Tier-1/2 PR #1445)

Nested support requires two design changes that are best made against a concrete
consumer rather than speculatively:

1. A tree input contract. Flat parse(schema, map<string,string>) can't carry
   nesting. It needs a second entry point — e.g. parse_json(schema, json_tree) —
   that walks a std.json DOM (keeping the flat parse for the common case).
2. A recursive value/error model. values becomes nested maps/lists; parse,
   to_json_schema, and the *_free functions all recurse. to_json_schema
   grows "type":"object"/"array" with nested properties/items.

The natural driver

contrib/tinyweb/schema_api currently flattens a JSON body's top-level scalars
into the flat input map (json_object_to_input). A nested-schema parse_json
would let it validate nested request bodies directly — that's the concrete
consumer that should shape the tree-input API.

Note / dependency

This work will lean on std.json's tree — see the companion issue about
json_free not fully reclaiming builder-constructed nested objects; the
nested-schema value model should avoid or account for that.

Part of the std.schema roadmap (Zod .object()/.array() parity). Tier 1
(defaults/transforms/checks) and Tier 2 (to_json_schema) landed in #1445.