fix: Remove AutoMapper dependency to remediate CVE-2026-32933

[JoseRenan]

Summary

Removes the AutoMapper 10.1.1 NuGet dependency to remediate CVE-2026-32933 (High severity, due 2026-06-12).

Replaces AutoMapper with explicit manual property-by-property mapping in a new \ConfigurationMapper\ class. No reflection is used — every mapped property is listed explicitly for auditability.

Why manual mapping?

Manual mapping is:

• Auditable: every property mapping is visible in code
• Compile-time safe: missing/renamed properties cause build errors
• Zero new dependencies: no Mapster, Mapperly, or other libraries introduced

What changed

Area	Change
\ConfigurationMapper.cs\	New — explicit \MapFrom()\ for each Args type + ConfigFile, \Merge(), \ToConfiguration()\
\ConfigPostProcessor.cs\	Removed \IMappingAction<>\ interface, simplified to plain class
\ConfigurationBuilder.cs\	Uses \ConfigurationMapper\ instead of \IMapper\
\ServiceCollectionExtensions.cs\	\AddTransient()\ replaces \AddAutoMapper()\
4 .csproj\ files	Removed AutoMapper package references
\Directory.Packages.props\	Removed AutoMapper version entries
\ConfigurationProfile.cs\ + 9 value converters	Deleted

Validation

• ✅ Build: 0 warnings, 0 errors
• ✅ All 829 unit tests pass
• ✅ E2E CLI tests: Generate, Validate, Redact, Aggregate, Config merge, Duplicate conflict detection, External SBOM validate

[github-actions]

This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:

• Changing the signature of an existing interface method
• Adding a new method to an existing interface
• Adding a required data member to a class that an existing interface method consumes

Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:

Option 1 - Publish this as a breaking change

1. Update the documentation to show the new functionality
2. Bump the major version in the next release
3. Be sure to highlight the breaking changes in the release notes

Option 2 - Refactor the changes to be non-breaking

1. Review this commit, which adds a new interface in a backward-compatible way
2. Refactor the change to follow this pattern so that existing interfaces are left completely intact
3. Bump the minor version in the next release

[KalleOlaviNiemitalo]

sbom-tool is in EOL/deprecation

That would be good to say in the README too, and in NuGet Gallery.

[github-actions]

This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:

• Changing the signature of an existing interface method
• Adding a new method to an existing interface
• Adding a required data member to a class that an existing interface method consumes

Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:

Option 1 - Publish this as a breaking change

1. Update the documentation to show the new functionality
2. Bump the major version in the next release
3. Be sure to highlight the breaking changes in the release notes

Option 2 - Refactor the changes to be non-breaking

1. Review this commit, which adds a new interface in a backward-compatible way
2. Refactor the change to follow this pattern so that existing interfaces are left completely intact
3. Bump the minor version in the next release

[sfoslund]

/azp run