proof: split the two possible runtime `Blob` interpretations into a concrete either type

Nobody has claimed this yet.

Today we have `Blob`:https://github.com/lightninglabs/taproot-assets/blob/cd916e7d7a7d0a98500cb97778b51b2aaf87d731/proof/mint.go#L14-L27

Originally it was ambiguous if this was a blob of the proof file, or a single state transition. Later on we added the magic byte prefix in front of both to be able to distinguish them.

Today the `[]byte` that is a `Blob` can be a serialized proof file, or a serialized state transition. Today, any code that interacts with this type needs to rely on _runtime_ level checks to make sure they're handling the contents directly.

To remedy this at the type sytem levl, during initial review, I recommened that we use an `fn.Either` here to capture the semantics of blob at the type level.

This would look something like:
```go
type FileBob []byte
type ProofBlob []byte

type Blob = fn.Either[FileBlob, ProofFileBlob]
```

Along the way, where applicable, we would update all code that uses `Blob` today to use one of those new types. For areas where we want to defer concrete mapping to either of those types, we'd start to use the new either based `Blob`. We may want to borrow the new map either funcs from the `lnd` repo along the way.

Start with the Blob definition in proof/mint.go and trace the code that currently consumes its []byte contents. Review the proposed fn.Either approach and the lnd map-either functions mentioned in the issue. Done means serialized proof files and state transitions use distinct concrete types wherever applicable, with Blob retained only where mapping is deferred.

Written by the indexing model from the issue text.