Stale values in repeated validation

When validating multiple SBOMs with the API, the location of the manifest to validate gets 'stale.' For example, if you validate SBOM A, then SBOM B, the attempt to validate B will erroneously look for a file at A's location.

This happens because the SbomConfigProvider is initialized as a singleton in the ServiceCollectionExtensions. So for the life of the service, the initial values added to the configsDictionary in the SbomConfigProvider will persist. We want these values to be refreshed per validation request, and to be the same as the values in the inputConfig of the SbomValidator.

Our suggested fix is to change line 162 of ServiceCollectionExtensions to use .addScoped instead of .addSingleton. However, we do not want to make changes to this area of the code until the validator has sufficient unit tests. So, this issue should be addressed by two PRs:

1. One to add unit tests to cover the SbomValidator (this may include one commented-out which would fail due to this bug).
2. Another to fix this bug (with all unit tests passing).

Start with src/Microsoft.Sbom.Api/SBOMValidator.cs and the SbomConfigProvider registration at line 162 of src/Microsoft.Sbom.Extensions.DependencyInjection/ServiceCollectionExtensions.cs. First add unit tests covering repeated validation with different SBOM locations, then verify the failing stale-value scenario and the existing validation behavior. Done means the validator tests pass and consecutive requests use each request’s inputConfig rather than retaining the first request’s values.