fix(core-spec): drop root-level dialects and vendors from the schema

[kayemkim]

Summary

#297 added two optional arrays, dialects and vendors, to the document root of core-spec/ossie-schema.json, described as closing a gap with the pydantic model. As laid out in #393, nothing else in the repository treats them as part of the spec: spec.md does not mention them, validate.py does not read them, the orionbelt suite asserts that the schema rejects them (it has failed on main since 2026-09-08, unnoticed because that workflow only runs on converters/orionbelt/**), and #148 and #306 remove them from the model and the converters. The answer on #393 was to take them back out and stop the converters emitting them, so this does that:

• core-spec/ossie-schema.json: the two root properties are removed, so the root is version and semantic_model again as before [OSSIE][SIGMA] Add bidirectional Sigma Computing data model converter #297. The SIGMA enum entries from [OSSIE][SIGMA] Add bidirectional Sigma Computing data model converter #297 stay.
• converters/sigma/src/ossie_sigma/sigma_to_ossie.py: the converter no longer sets dialects/vendors on the emitted OssieDocument. The per-expression SIGMA dialect entries and the SIGMA custom extensions are untouched, so nothing is lost for round-tripping. The 91 sigma tests pass unchanged, and the three fixtures converted through the CLI now validate against the schema (on main their output carries both root keys).
• validation/test_validate.py: one integration test that a document with the two root keys fails validation with Additional properties are not allowed. The orionbelt test already covers this, but behind its path filter; the validation workflow runs on every core-spec/** change, which is where the properties came in.

dbt still emits a root dialects and Honeydew still carries vendors through. Both are removed by #306 (and #148), which I left alone rather than duplicate. With this merged, #306's extra="forbid" on OssieDocument also becomes safe for the Sigma converter: on main, #306 by itself fails 32 sigma tests because the converter sets the fields it forbids, while #306 merged on top of this branch passes python, dbt, honeydew, sigma and validation.

Two open PRs carry the root properties forward and will conflict with whichever lands second: #383 keeps them in the flattened root, and #396 moves them into the Sigma OssieDocument call and asserts them in test_roundtrip.py. I merged each on top of this branch; in both cases the resolution is to drop them. The new validator test is written against today's semantic_model wrapper and moves to the flat form if #383 goes first.

This is a breaking change for any document that added root dialects/vendors since 2026-09-08. Nothing in the repository produces one apart from the converters named above.

Related Issues

Closes #393. Relates to #148, #306, #383, #396.

Checklist

Specification

• Spec changes are included in core-spec/ and follow the existing structure
• Spec changes have been discussed on the mailing list or in a linked issue
• Breaking changes to the spec are clearly called out in the summary

Ontology

• Ontology changes in ontology/ are consistent with spec changes
• New or modified terms are defined and documented

Converters

• Converter logic in converters/ is updated to reflect spec or ontology changes
• New converters include tests under the converter's test directory

Validation

• Validation rules in validation/ are updated if the spec changed
• New validation cases are covered by tests

Documentation

• docs/ is updated to reflect any user-facing changes
• New features or behaviors are documented with examples where appropriate
• CONTRIBUTING.md is updated if the contribution process changed

Examples

• examples/ are added or updated for any new spec constructs or converter support

Tests

• All existing tests pass (pytest / CI green)
• New functionality is covered by tests

Compliance

• ASF license headers are present on all new source files
• No third-party dependencies are added without PMC/IPMC approval