multi: relax trailing byte handling for DB blocks and PSBT readers

[Roasbeef]

In this PR, we address a few follow-ups to the trailing byte hardening that landed in #2558.

Tolerate trailing bytes in the node's own database

Databases written by older versions of btcd may have persisted blocks with trailing bytes: the old submitblock path and the pre-hardening p2p path both accepted them, and ffldb stores the raw bytes verbatim. With the strict loading added in #2558, such a block at the chain tip would prevent the node from ever starting, and a block deeper in the chain would fail getblock, reorg handling, and indexer catch-up, with no recovery path short of a full resync.

We now load database blocks via a new blockchain.DBBlockFromBytes helper (used by initChainState and dbFetchBlockByNode) that parses leniently: any trailing bytes are logged, ignored, and stripped from the serialization cached on the returned block, so downstream consumers of the raw bytes never observe them. The external ingress paths (RPC, p2p, PSBT) remain strict, this only relaxes reads from the node's own database.

The final commit extends the same treatment to the two remaining call sites that re-parse own-DB blocks strictly: the getblock RPC (which also served the dirty bytes verbatim at verbosity 0, and counted them in Size) and the index manager's init path, which loads orphaned blocks directly from the database when rolling an index tip back to the main chain. Both now go through the shared helper, so getblock serves the exact block serialization at every verbosity level. We can't route getblock through Chain.BlockByHash here since that rejects side chain blocks, which getblock serves today.

Fix blocking reads and unbounded allocations in PSBT parsing

The trailing data check in NewFromRawBytes probed the caller supplied reader with a blocking one byte read, so a reader without a Len method (a net.Conn, an io.Pipe) that stays open after delivering a complete packet would hang the parser forever. We now only enforce the check when the reader can report its remaining length without an additional read, which covers in-memory readers along with the decoded base64 path, and we document the reader contract on NewFromRawBytes.

The base64 path also read the entire input into memory before any validation ran, so a very large input could force an arbitrarily large allocation before the first validity check. We now bound the read to wire.MaxMessagePayload expanded by the base64 encoding overhead.

Steps to Test

Each fix ships with a regression test: startup with a trailing byte tip block now succeeds (with the trailing byte excluded from the recorded block size), DBBlockFromBytes strips trailing bytes from the cached serialization while still rejecting truncated blocks, a stream reader is never probed past the packet, and oversized base64 input is rejected (pinned with an erroring sentinel reader so the size bound itself is exercised). Run go test ./blockchain/ ./blockchain/indexers/ in the root module and go test ./... in the psbt module.