(GH-538) Enhance schema export functionality and add error handling for duplicate paths

[Gijs Reijn (Gijsreyn)]

PR Summary

The primary purpose of this change is to make cargo xtask schema export reliable and complete enough to publish versioned DSC schemas from source code. It fixes two silent output collisions, exports every type that derives DscRepoSchema, and adds version targeting so the exporter can produce any recognized schema version folder instead of only vNext.

As a maintainer or contributor, you can now invoke:

• cargo xtask schema export — exports schemas/vNext as before.
• cargo xtask schema export --schema-version v3.2 --schema-version v3.2.3 — exports specific version folders.
• cargo xtask schema export --release 3.3.0 — exports the full set a release must publish: schemas/v3.3.0, schemas/v3.3, and schemas/v3.

PR Context

As part of #538 and following up on #1406, the exporter needs to produce correct, complete, versioned schemas from source before it can replace the hand-maintained YAML pipeline under schemas/src.

[Copilot]

Pull request overview

This PR improves the reliability and completeness of the Rust-based schema export pipeline (cargo xtask schema export) so schemas can be generated from source and published in versioned folders without silent collisions.

Changes:

• Add duplicate-path detection during schema export to prevent silent overwrites when two types resolve to the same output path.
• Extend xtask schema export to support exporting explicit schema version folders and expanding a --release X.Y.Z into patch/minor/major version folders.
• Improve schema-version parsing ergonomics and align several schema IDs/paths so exported locations match the intended repository layout.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
xtask/src/schemas/export.rs	Adds duplicate export-path detection and expands the exported type list.
xtask/src/main.rs	Adds --schema-version / --release resolution logic and tests for version resolution.
xtask/src/args.rs	Extends CLI args for schema export to accept repeated schema versions or a release expansion.
xtask/locales/en-us.toml	Adds localized help/error strings for the new schema export options and errors.
lib/dsc-lib/src/dscresources/invoke_result.rs	Adjusts schema export base name to avoid output collisions.
lib/dsc-lib/src/dscresources/adapted_resource_manifest.rs	Fixes schema export folder path and broadens $schema validation to accept relevant URIs.
lib/dsc-lib-jsonschema/src/dsc_repo/recognized_schema_version.rs	Implements FromStr + error type for schema version folder parsing, with tests.
lib/dsc-lib-jsonschema/src/dsc_repo/mod.rs	Re-exports UnrecognizedSchemaVersion for downstream use.
lib/dsc-lib-jsonschema/locales/en-us.toml	Adds i18n strings for schema-version parsing errors.
dsc/src/util.rs	Switches CLI/server schema generation to use DscRepoSchema generation (bundled vs canonical based on type).

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Mikey Lombardi (He/Him) (michaeltlombardi)]

Should this more correctly be resource/adapted? It's a data object that represents a specific kind of resource manifest, but it's still semantically there - and many of the fields reuse the same definition as the typical resource manifest.

Suggested change

	folder_path = "adaptedresource",
	folder_path = "resource/adapted",

[Mikey Lombardi (He/Him) (michaeltlombardi)]

What is the reason for using this special associated function instead of recognized_schema_uris_subschema() on this type (I see that it was previously using the same subschema as the ResourceManifest, which was incorrect)?