Integrate H5Lens with HDFGroup/cve_hdf5

[gheber]

Should HDFGroup/cve_hdf5 continue on its own or be incorporated into H5Lens?

[gheber]

Pros and cons of retaining the separate repository

Keeping cve_hdf5 separate has real advantages:

• It remains a general libhdf5/tool regression archive usable by projects other than h5policy.
• Upstream contributors do not need to understand this repository’s finding registry, profiles, or promotion workflow.
• Historical advisory and fix-release maintenance does not churn the policy implementation.
• Its permissive license can remain clearly attributed; vendoring should retain its cve_hdf5/COPYING:1.

The disadvantages are mostly synchronization problems:

• A new specimen, its metadata, its execution command, and a new validator rule cannot land atomically.
• Independent lists drift—as the current inventory demonstrates.
• A sibling checkout or CI download cannot satisfy “exercise on every test” reliably.
• Historical advisory claims may be mistaken for current evidence. In this repository, the old files remain valuable
  attack-surface specimens, but current conclusions must be re-measured against the newest libhdf5.

Preliminary conclusion

The vendored-consumer model retains the advantages while controlling the drift through revision and digest pins.