Keyed bao? #76

Love what you've done with bao-tree, especially the runtime chunk groups. I think we will go with 4KB for Carbonado v2 because it aligns well with 4KB SSD / HDD sectors, though the inboard-encoded checksum might bleed over slightly.

In Carbonado we have a 4-bit format mask encoded as a byte, so the same data can produce different Bao roots depending on the pipeline. For the data market stuff we're thinking about (see bitmask-stack/carbonado#10), it would be really useful if the root could commit to the format byte because we would know immediately whether the data was encrypted or not. It doesn't make sense to make storage markets with encrypted blobs since you can't know if they're just random nonsense. Carbonado basically cryptographically proves the actual data pipeline used to create the data. This could allow for storage markets to more efficiently account for duplicates in calculating replication factor. Older rarer transparent unencrypted data is more valuable so it provides a market incentive to retain rare old data for posterity and proving its value and uniqueness across an OpenTimeStamps index.

Would you be open to adding a minimal keyed tree mode, either using blake3's keyed mode or whatever approach you think makes most sense? Happy to help implement it.

Thanks for the work on all this, looks like great improvements.