As seen the check_topological order fails for this new Decision Tree added.

Sorry, I should have made a PR against your branch rather than just pushing to it. But here's what I did:

1. I observed that even though the combination of EQ3==2 (L) AND EQ6==0 (H) is invalid in CVSSv4 we can still create rows for them in our DecisionTable.mapping to satisfy the DecisionTables must have full-coverage of the input space requirement.
2. I tried adding a "Not Valid" value to the LMHC DecisionPoint but no matter where I put it in the LMHC.values tuple, it consistently caused topology check errors.
3. To work around the topology check errors, I decided to set the "invalid" rows from 1 such that their outcome would be the same as the corresponding (and valid) row where EQ3==2 (L) AND EQ6==1 (L).
4. To prepare for testing, I generated a "known valid" list of dicts in the mapping format based on https://github.com/FIRSTdotorg/cvss-v4-calculator/blob/main/cvss_lookup.js into test.decision_tables.cvss._v4_expected
5. I created unit tests to confirm that
   a. All the expected rows corresponding to valid MacroVectors are present and accounted for in the mapping.
   b. For the "invalid" MacroVectors, ensure that the outcome for EQ3==2 (L) AND EQ6==0 (H) matches the outcome for EQ3==2 (L) AND EQ6==1 (L)

If anyone were to try to implement a full multi-stage CVSS v4 categorizer using SSVC, then the combination of inputs to the EQ3 and EQ6 DecisionTables should preclude anyone from ever reaching the "invalid" rows of the QSR_4 DecisionTable. The only way you could even get to those "invalid" rows would be if you were going directly to the QSR_4 table, and that would be a very odd thing to do indeed. And even if you did, you'd get the same answer as if you had instead chosen the lower option for EQ6.

In the (somewhat likely #800) case that in the future we make a DecisionTable "downselect" object (i.e., one that allows incomplete coverage over input states so that it can represent the state of knowledge in the context of a policy represented by a DecisionTable), then we would probably want to make a special case of it for CVSSv4 that explicitly drops the "invalid" rows on creation, since they're only there to satisfy the current DecisionTable full-coverage requirement.