btcutil/wif.go: private key material not zeroed in several code paths

[Lrifton92]

Follow-up from the review discussion on #2545. While adding defer keyScalar.Zero() to DecodeWIF, @allocz noted that btcutil/wif.go has several other code paths where memory holding private-key material is not zeroed after use. Opening this to track a broader audit of key-zeroing hygiene across wif.go and to confirm the desired behavior against the project's security assumptions, separate from the scoped fix in #2545.

Refs #2545.

[allocz]

Also note that doing calculations containing sensitive material inside a big.Int can also cause the leak of sensitive data. In those cases, would be nice to audit the big.Int procedures used, or even stop using big.Int with data that we don't want to leave unzeroed in memory. Using the package runtime/secret may also help, but for now this package still in experimental state.

[Lrifton92]

Thanks @allocz — that's a fair point and a real leak class: big.Int gives no reliable way to scrub its backing store (the nat digit slice can be grown/reallocated and there's no exported zeroing), so any secret transiting a big.Int can linger in memory.

I'd like to keep this issue scoped to wif.go key-zeroing hygiene — a small, reviewable surface that follows directly from #2545. The big.Int concern is broader (it reaches btcec, key/WIF (de)serialization, and anywhere scalars are handled), so folding it in here would make the fix hard to review and merge.

Proposal: land the wif.go zeroing first, and I'll open a separate tracking issue for the big.Int sensitive-data audit — candidate paths, plus whether ModNScalar / fixed-size byte arrays can replace big.Int on the secret paths. runtime/secret is worth watching but, as you note, still experimental, so I wouldn't build on it yet.

Does that split match what maintainers would prefer, or would you rather track both here?