chore: explicitly reject share commitments that are not == hash len

[evan-forbes]

Overview

Noticed this while I was writing the block validity rules. This was still failing as expected since the commitment is check, but now we're being more explicit.

Checklist

• New and updated code has appropriate documentation
• New and updated code has new and/or updated testing
• Required CI checks are passing
• Visual proof for any user facing features like CLI or documentation updates
• Linked issues closed with keywords

[codecov-commenter]

Codecov Report

Merging #1867 (a794531) into main (348f795) will increase coverage by 21.80%.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##           main    #1867       +/-   ##
=========================================
+ Coverage      0   21.80%   +21.80%     
=========================================
  Files         0      117      +117     
  Lines         0    13306    +13306     
=========================================
+ Hits          0     2901     +2901     
- Misses        0    10114    +10114     
- Partials      0      291      +291     

Impacted Files	Coverage Δ
x/blob/types/payforblob.go	71.42% <100.00%> (ø)

... and 116 files with indirect coverage changes

[cmwaters]

LGTM. I don't know what our stance is towards clearer error messages. I can imagine returning ErrInvalidShareCommitment in this scenario would be relatively confusing to users. It would be also helpful now we have multiple share commitments to return which one was invalid by wrapping the error