test(cross-draft): respect $schema when it follows $defs

[Lakshya77089]

Adds a test asserting that the dialect declared by $schema is applied to subschemas under $defs even when $defs appears before $schema lexically. This covers the "keyword ordering MUST be insignificant" banner raised in the linked issue.

The reported bug: an implementation that builds the $defs subschemas before reading $schema ends up using its default dialect rather than the one the schema declares.

How the test detects it

{
    "$defs": { "list": { "prefixItems": [{ "type": "string" }], "minItems": 2 } },
    "$ref": "#/$defs/list",
    "$schema": "https://json-schema.org/draft/2019-09/schema"
}

prefixItems is not a keyword in 2019-09, so [1, 2, 3] is valid only if the implementation read $schema (and selected the 2019-09 dialect) before building $defs. An implementation that defaulted the dialect would treat prefixItems as an assertion and reject the array — failing the valid: true test. minItems (recognized in both dialects) gives a stable invalid case as well.

The case lives in optional/cross-draft.json because detecting the bug inherently requires a root $schema that differs from the folder's default dialect, which is the same situation the existing cross-draft cases exercise. tests/latest is a symlink to draft2020-12, so it is covered automatically.

Verified locally: structurally valid against test-schema.json, valid under the 2020-12 metaschema (check_schema), and a $schema-respecting reference implementation returns the expected true/false.

Note for reviewers

I added this only in the 2020-12 → 2019-09 direction. The mirror (an older-draft folder declaring a newer inner $schema) trips the suite's test_arbitrary_schemas_do_not_use_unknown_keywords guard when the newer keyword appears inline, and the clean older-dialect discriminators tangle with $ref-sibling semantics. Happy to add the other direction via remotes if that's preferred.

🤖 Generated with Claude Code

[jdesrosiers]

I'm not convinced that this test is necessary. If you can find an implementation that fails this test, then we should adding it, but otherwise I don't think it's needed.

(Hint: You can use the bowtie CLI to run your test against every implementation supported by bowtie.)

[jdesrosiers]

I just read, #941 which this appears to be in response to. Please add Resolves #941 to the PR description.

[jdesrosiers]

This test assumes that the default dialect is 2020-12, but never actually states that assumption. Since this test relies on configuration (setting a default dialect), putting it in "optional" is the right choice because implementations aren't required to have a default dialect.