In a container scenario, depending on orchestration used, it is generally possible for a user to limit CPU quota and level of parallelism.
One does not imply another. That is why there are distinct knobs.

Example: on a machine with 4 cores, it is conceivable to have 8 containers limited to 1/8 of total CPU time for fairness/over-committing, but

1. each limited to using 1 CPU at a time. This would favor compute-intensive scenarios.
   OR
2. each having access to all 4 CPUs. This would favor latency sensitive, IO-performing, bursty workloads.

It looks like coreclr may see no distinction between these cases and treat them both as #1.

There is a common pattern where once the quota falls below user-set Core count, we reduce the available Core count to match the quota.

User could ask for reduced parallelism, but did not.
Even if user might be doing this by accident, perhaps that should be respected? Otherwise, if there is a legit need for #2, it cannot be done.

==
https://github.com/dotnet/coreclr/blob/1d78ed88ff9078febdbb5c37173b313da5c023a3/src/utilcode/util.cpp#L1294

https://github.com/dotnet/coreclr/blob/31acad70cae93caf0afe753775f14ebe80db31ed/src/classlibnative/bcltype/system.cpp#L358

https://github.com/dotnet/coreclr/blob/31acad70cae93caf0afe753775f14ebe80db31ed/src/classlibnative/bcltype/system.cpp#L358