AddFileWithHash rejects hashes that are not multihashes (closes #129)

AddFileWithHash took any non-empty bytes as a hash, so the builder could
write a manifest that mfer refuses to load. It now decodes the hash with
go-multihash and also requires a digest of at least 32 bytes, the SHA-256
length the reader's decoding-cost limit assumes: a valid but shorter
multihash, such as an empty identity hash or SHA-1, still makes a
manifest of one-character paths too costly to load. When mfer freshen
meets such a hash in an existing manifest, its error names the manifest
entry and says to regenerate the manifest with mfer generate. Test
fixtures whose stand-in hashes were not valid multihashes now use a
SHA-256 multihash.

Model: opus-5-5

mfer/constants.go

@@ -36,7 +36,8 @@ const (
 	decodedMIMETypeSize  = 16
 
 	// Each file entry mfer writes holds a path of at least one byte, a
-	// 34-byte SHA-256 multihash and a modification time: at least 47 bytes,
+	// multihash at least as long as SHA-256's 34 bytes (AddFileWithHash
+	// refuses shorter ones) and a modification time: at least 47 bytes,
 	// counted at 336. So its manifests add up to at most about 7.15 times
 	// their size, and this limit is about 12% above that.
 	maxDecodedGrowth = 8