fix(fr32): correctly calculate the todo size under low core counts

[tediou5]

Related Issues

Fixes #9324
Based on #12491.

Proposed Changes

Currently, the unpadReader's work size is calculated using MTTresh * mtChunkCount(sz). When the core count is low, this may cause the todo length to exceed len(work).

In the current implementation, the length of out is actually expanded automatically by Go's underlying mechanisms, making adjustments quite troublesome.

// io.go
func ReadAll(r Reader) ([]byte, error) {
  b := make([]byte, 0, 512)
  for {
    n, err := r.Read(b[len(b):cap(b)])
    b = b[:len(b)+n]
    if err != nil { /* ... */ }

    if len(b) == cap(b) {
      // Add more capacity (let append pick how much).
      b = append(b, 0)[:len(b)] // <-- here
    }
  }
}

There are two feasible solutions:

1. Increase the minimum mtChunkCount to 16.
2. Ensure that todo does not exceed the size of work.

I'm not entirely sure if other conditions could also lead to similar issues, so for now, I've chosen the second approach. I added a check when calculating todo to prevent overflow:

todo := min(abi.PaddedPieceSize(outTwoPow), abi.PaddedPieceSize(len(r.work)))

Additionally I’ve also fixed the CI.

Additional Info

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title conforms with contribution conventions
• Update CHANGELOG.md or signal that this change does not need it per contribution conventions
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green