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 內容生成。