It feels weird to me that this is being recomputed and reverified on every single run with every single algorithm. It's probably fine, but I'd probably just declare 9 as a local const and leave a comment as to how that value was determined.

What really matters is that it tests "one below this doesn't call the Core method, and at this size it does". So maybe I'd omit the comment, as const int MinimumOverhead = 9; says "it's a minimum" and then the test confirms it's the same minimum that the implementation uses.

There's room to argue if we want the minimum to be 9, or if we want to say that since we have a finite list of SlhDsaAlgorithm and we know they all have a minimum of (whatever it is) that we're going to push the impl limit higher. Again, it doesn't matter a whole lot to the test why we picked that number, but it would have to match if it's testing the boundary.

it doesn't matter a whole lot to the test why we picked that number

I think it's worth having both the following tests: (1) the number we picked is honored in the implementation and (2) the length check will permit a minimal encoding. And by minimal encoding, I mean either a hardcoded or runtime generated ASN encoding for each algo that we believe is the smallest spec compliant PKCS#8 encoding.

If we don't have (2) it becomes very easy to just update the constant in the product and in the failing test and nothing really gets validated. By having (2) it forces us to provide a new minimal encoding to prove that the new constant still satisfies the constraint of allowing the minimal encoding.

Also, the overhead right now does not account for the Version so I'll add it in.