fix(schema): handle constraints that reduce to root nodes

[chris-kreidl]

Fixes minLength: 0 (and similar trivially-satisfied constraints) causing parse errors when used in JSON schemas.

Example JSON Schema:

{
	type: "string",
	minLength: 0
}

The minLength reducer correctly identifies a minLength of 0 as trivially satisfied and returns $ark.intrinsic.unknown

However, constraintKeyParser didn't really account for the possibility that we might be dealing with a root node after the reducer's done its thing, instead treating it as a constraint. It would then be added to the intersection schema as 'intersection', which is invalid.

This PR changes constraintKeyParser to return undefined when constraints are trivially satisfied, ultimately removing them from the generated schema.

The test suite then caught another bug and perhaps an implicit workaround for that bug.

pipe.test.ts contains a test that looks for the following error:

ParseError: An unordered union of a type including a morph and a type with overlapping input is indeterminate:
Left: { foo: (In: string ) => Out<Date> | false | true }
Right: { foo: (In: string) => Out<{ [string]: $jsonObject | number | string | false | null | true }> | false | true }

Of note is the whitespace after string in Left: that isn't there in Right:

This is addressed in the change to ark/schema/roots/intersection.ts

And, because that change made the above test fail, I've updated the expected error message in that test.

Finally, I've added a test to the json-schema suite to ensure that a string-type schema can accept a minLength of 0

• Code is up-to-date with the main branch
• You've successfully run pnpm prChecks locally
• There are new or updated unit tests validating the change

[ssalbdivad]

Hey this is great! Hadn't considered how these constraints within ArkType would affect parsing from JSON Schema- thanks for the fix!