Java: PQC API misuse queries for experimental/quantum - wanted, and against which layer?

**Description of the issue**

I have a set of CodeQL queries for Java that detect *misuse of post-quantum APIs*, and I would like to check whether they are wanted here, and in what shape, before opening a PR.

The existing `experimental/quantum` work answers "which cryptography is quantum-vulnerable and where is it": the CBOM graph, the `InventorySlices` queries, and the `QuantumVulnerable*` demo queries in #21354. The gap I am proposing to fill is the other direction: code that has already adopted ML-KEM or ML-DSA and wires it up incorrectly. Those are ordinary implementation bugs, but they are invisible to inventory queries because the algorithm inventory looks correct.

Eight patterns, all targeting the KEM and PQC signature APIs:

| ID | Pattern |
|---|---|
| KEM-01 | KEM ciphertext used as key material |
| KEM-02 | Raw ML-KEM shared secret used as a symmetric key with no KDF |
| KEM-03 | Shared secret truncated |
| KEM-04 | Static or reused KEM keypair, losing forward secrecy |
| HYB-01 | Hybrid key exchange silently downgrading to the classical component |
| SIG-01 | Signature verification result ignored |
| SIG-02 | Predictable RNG for key generation |
| API-01 | Deprecated pre-standardization Kyber/Dilithium APIs instead of FIPS 203/204 |

**Does it find real bugs?** On `gematik/lib-vau@a583b04`, currently the head of `main`, which is the reference implementation of the VAU protocol for Germany's national electronic patient record, API-01 reports three true positives: `KyberParameterSpec.kyber768` in `KyberEncoding.java:58` and `KeyFactory.getInstance("KYBER", "BCPQC")` in `VauBasicPublicKey.java:80`. Both are BouncyCastle's round-3 API rather than FIPS 203 ML-KEM. Their round-3 pin appears deliberate for spec compliance, so this is a migration-liability finding rather than an exploitable bug, but the detection itself is accurate.

As a check in the other direction, all eight queries report nothing on `i2p/i2p.i2p@e52a015`, which uses ML-KEM correctly by feeding the shared secret into a Noise HKDF chain. That zero is not an extraction artifact: a probe query confirms the database resolved `MLKEMExtractor.extractSecret`, `MLKEMGenerator.generateEncapsulated` and `SecretWithEncapsulation.getSecret`. The KEM-02 detector uses value-preserving local flow, so a KDF on the path stops the flow and correct code is spared without needing an allowlist of KDF APIs.

Beyond that I only have a self-built labelled corpus (24 sites), which I would not present as generalization evidence.

**What I would like to know before doing the work:**

1. Are misuse queries of this kind wanted in `java/ql/src/experimental/quantum`, or is that directory intended to stay inventory and classification only?
2. Should they be built on the crypto model rather than plain AST plus dataflow? As far as I can tell the model does not yet reach the APIs these queries target. `JCA.qll` recognises ML-KEM by name but maps it to `Crypto::OtherKeyAgreementType()`, `javax.crypto.KEM` (JDK 21 and later) does not appear in `JCA.qll` at all, nor does BouncyCastle's low-level `MLKEMGenerator`/`MLKEMExtractor` pair, and `KeyEncapsulationOperationNode` in `Model.qll` is keyed to wrap and unwrap modes rather than encapsulate and decapsulate. `TKeyEncapsulation(OtherKEMAlgorithmType())` appears only as a documented type hint. The `library-tests/quantum/jca/KeyEncapsulation.java` fixture looks like it was heading this way, since its Kyber section and the BouncyCastle PQC imports are commented out, and its own javadoc notes that "directly using the raw ECDH shared secret as key material is insecure in production", which is the classical sibling of KEM-02 in the table above. So the choice looks like either extending the model with KEM operation instances first and writing the queries on top, or writing them against the Java AST and dataflow for now and migrating later. I would rather follow your preference than guess.
3. If this is welcome, would you prefer one query first (API-01 is the one with the real-world true positive) so the shape can be reviewed, rather than eight at once?

Happy to do the porting, `@tags experimental`, `java/` query IDs, autoformatting, qhelp and tests. I would rather ask first than send eight queries written against the wrong layer. The queries and evidence are at https://github.com/Arpan0995/pqc-api-misuse-codeql (Apache-2.0).

首先检查误用查询是否属于 java/ql/src/experimental/quantum，以及它们应使用密码学模型还是 Java AST 和 dataflow。然后检查 JCA.qll、Model.qll 和 library-tests/quantum/jca/KeyEncapsulation.java。完成的标准是确定一致认可的范围和层，随后提供一个经过审查的原型，其中包含查询 ID、qhelp、标签和测试。

由索引模型根据 Issue 内容生成。