Add a post-quantum migration CBOM example

## Summary

The CBOM examples currently demonstrate individual algorithms, including ML-KEM-1024, and basic component-to-cryptographic-asset dependencies. They do not yet show how a real application can represent a staged post-quantum migration in which standardized post-quantum and classical cryptography coexist.

I would like to contribute a schema-valid CycloneDX 1.7 example that models that operational migration state. The intended audience is implementers building CBOM generators, migration inventories, and policy checks rather than readers looking for an exhaustive cryptographic tutorial.

## Proposed example

Add a directory such as `CBOM/Post-Quantum-Migration/` containing a short README and JSON BOM for a Python application using a cryptographic library that provides:

- ML-KEM-768 for key encapsulation;
- ML-DSA-65 for signatures;
- a classical key-establishment/signature asset retained during a transition period;
- explicit application -> library -> cryptographic-asset relationships;
- distinct assets for standardized ML-KEM/ML-DSA names and any legacy Kyber/Dilithium identifiers represented by the fixture.

The example would populate only properties supported by the 1.7 schema, including the algorithm family, primitive, parameter-set identifier, NIST quantum-security level, crypto functions, implementation context, and stable `bom-ref` values. It would avoid implying that inventory presence alone proves protocol-level security or migration completion.

## Proposed source fixture and provenance

The BOM would be derived from a small, reproducible Python fixture reduced from [`AAH20/AAH_PostQuantum_Cryptography`](https://github.com/AAH20/AAH_PostQuantum_Cryptography), with only the imports, algorithm selection, and relevant operations retained. This keeps the example inspectable without requiring `liboqs` execution.

Disclosure: I maintain that implementation and work through [A2Z SOC](https://a2zsoc.com/), where the practical service tied to this work is a PQC migration readiness assessment: cryptographic discovery, harvest-now-decrypt-later prioritization, migration planning, and post-change validation. The proposed repository content itself would remain vendor-neutral and would not contain sales language.

## Acceptance criteria

- validates against the official CycloneDX 1.7 JSON schema;
- represents ML-KEM-768 and ML-DSA-65 as separate cryptographic assets;
- includes at least one classical asset to make the transition state explicit;
- connects the application, implementation library, and assets through dependency relationships;
- documents why `nistQuantumSecurityLevel: 0` on a classical public-key primitive differs from the level on ML-KEM/ML-DSA;
- does not classify unresolved or dynamically selected algorithms as quantum-safe;
- uses deterministic identifiers and contains no keys, ciphertexts, signatures, or other generated material;
- passes the repository's existing validation and formatting checks.

## Out of scope

- recommending a deployment architecture or protocol;
- treating a CBOM as proof of correct cryptographic implementation;
- adding new schema fields;
- cataloguing every liboqs mechanism;
- changing the existing algorithm examples.

Would the maintainers prefer this as a dedicated `Post-Quantum-Migration` example, or as an extension of `CBOM/Example-With-Dependencies`? If the direction is welcome, I can submit the JSON, README, source fixture, and validation output as one focused PR.