Upgrade Core to 1c2f2011df7c37543265ad5d89153189b4649013

[jviotti]

Signed-off-by: Juan Cruz Viotti jv@jviotti.com

[augmentcode]

🤖 Augment PR Summary

Summary: Updates the vendored Sourcemeta Core dependency to 1c2f2011df7c…, bringing in new Core features and behavior changes that affect schema canonicalization and parsing callbacks.

Changes:

• Bump Core revision in DEPENDENCIES and sync the vendored vendor/core tree.
• Add a new Core HTML component (CMake option + HTML encoder/escape + HTML element helpers).
• Harden compiler mapper rules by requiring schema.is_object() before checking schema keywords.
• Revise JSON/YAML parse-callback APIs to pass parse context (root/property/index) and avoid allocating temporary JSON values for callbacks.
• Extend JSON Schema framing/walking with property_name tracking and improved keyword validation via SchemaKeywordError.
• Expand AlterSchema transformations (new simplifications, implicit items, empty-object/boolean simplifications) and update canonicalizer + e2e expected outputs (notably adding items: true in canonical forms).
• Update EditorSchema conversion to require already-bundled inputs and optimize reference rewriting lookups.

Technical Notes: This upgrade introduces observable output/API changes (canonical forms, parse callback signatures), so downstream tooling and tests need to stay aligned with the new Core semantics.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 3 suggestions posted.

Comment augment review to trigger a new review at any time.

[augmentcode]

Erasing anyOf because it has a true/{} branch can change evaluation/annotation behavior in newer drafts (e.g., unevaluatedProperties/unevaluatedItems depends on which applicators are present), even though the assertion outcome is unchanged. Consider constraining this rule to dialects/vocabularies where those semantics aren’t relevant (or explicitly documenting the intended tradeoff).

_{🤖 Was this useful? React with 👍 or 👎}

[augmentcode]

Adding items: true is assertion-equivalent for many schemas, but it can affect evaluation semantics in drafts that support unevaluatedItems (items may become "evaluated" where they previously weren’t). Consider limiting this rule when the Unevaluated vocabulary is present, or clarifying the intended behavior for unevaluated-keyword consumers.

_{🤖 Was this useful? React with 👍 or 👎}

[augmentcode]

SchemaKeywordError stores message_ as a const char*; if callers ever pass a non-static buffer, what() can dangle and become UB. Since this is a public exported exception type, an owning message representation would be safer.

_{🤖 Was this useful? React with 👍 or 👎}