fix: thread checkSchemas through IfcxLayerStack so --no-validate works

[mikan-atomoki]

Fix: make compose --no-validate actually disable schema validation

Fixes #133

What

compose parses --no-validate correctly, but validation still always runs: IfcxLayerStackBuilder.Build() constructs IfcxLayerStack, whose constructor eagerly runs Compose() → LoadIfcxFile(this.federated) with checkSchemas defaulting to true (layer-stack.ts#L15-L32, workflows.ts#L24). The SchemaValidationError escapes before the CLI's own (correct) LoadIfcxFile(federated, validate, true) call is ever reached (ifcx-cli.ts#L102-L109).

This PR threads a checkSchemas: boolean = true parameter through IfcxLayerStack's constructor and IfcxLayerStackBuilder.Build(), and passes the CLI's parsed validate flag into .Build(validate). Defaulting to true keeps every other caller's behavior unchanged; the style mirrors the optional boolean LoadIfcxFile already uses.

main is still at 02b0b21aaa4ab10354cdf931a6ec0d704d6e8d22 (the commit this patch was written and verified against), so no rebase was needed.

Repro

bad-type.ifcx — schema-declared Integer attribute holding a string (plain schema violation, no null semantics involved)

{
    "header": {
        "id": "poc/repro/bad-type.ifcx",
        "ifcxVersion": "ifcx_alpha",
        "dataVersion": "1.0.0",
        "author": "poc",
        "timestamp": "2026-07-22"
    },
    "imports": [],
    "schemas": {
        "test::count": {
            "uri": "https://example.com/poc/repro/test-count",
            "value": { "dataType": "Integer" }
        }
    },
    "data": [
        {
            "path": "aaaaaaaa-0000-0000-0000-000000000001",
            "attributes": { "test::count": "this-is-not-an-integer" }
        }
    ]
}

Before this PR, both of these crash with the byte-identical SchemaValidationError stack trace:

node ifcx-cli.js compose --no-fetch bad-type.ifcx out.json
node ifcx-cli.js compose --no-fetch --no-validate bad-type.ifcx out.json

Verification

• compose --no-fetch bad-type.ifcx out.json (no flag) → still throws SchemaValidationError, unchanged (exit 1)
• compose --no-fetch --no-validate bad-type.ifcx out.json → now exits 0 and writes the composed output
• npm test in src/ (28 existing cases in src/test/test.ts, including the layerStack builder suite) passes identically before and after the patch (28/28, 0 failures)

Note: alternative fix considered

In this code path the CLI only uses layerStack.GetFederatedLayer(); the constructor's eagerly-built tree is computed, validated, and then discarded. A larger alternative fix would make Compose() lazy (run on first GetFullTree()), removing the wasted validate+compose pass entirely — but that changes when validation errors surface for other callers of IfcxLayerStack, so this PR takes the minimal route instead. Happy to rework in that direction if you prefer it.

Related: this unblocks observing the composition engine's actual null-attribute semantics through the CLI — see the companion issue (#132) about Validate() rejecting null overrides that compose.ts is built to retain.