Kris Nuttycombe

I just revisited this, and it looks like there isn't an actual inconsistency; it's just that `min_confirmations == 0` is not respected (it's always effectively set to have a floor...

[force-pushed](https://github.com/zcash/librustzcash/compare/56cfd26e6ba1cb47275b152bc9a9245256049300..334d798a13891033b98d9153d59d9ae9fe5b0e7f) to address flushed comments from code review.

Then [force-pushed](https://github.com/zcash/librustzcash/compare/334d798a13891033b98d9153d59d9ae9fe5b0e7f..8586b1d4fcc42fbd81e2c387544df6b8791b5a99) to rebase on `main`.

[force-pushed](https://github.com/zcash/librustzcash/compare/405d2132b2c6cf6d3e0bd528db4a37cbefb487f5..640445fb9cf22a7ef1a4ae06d2c1d482cc042345) to address comments from code review.

Then [force-pushed](https://github.com/zcash/librustzcash/compare/640445fb9cf22a7ef1a4ae06d2c1d482cc042345..6c32fbd73e53092b54b06bfdbc9593adae4beef3) to rebase and resolve conflicts with `main`.

> Why does the wallet consider the transparent transaction's output eligible for shielding, even though it should believe it to be expired? Given all the recent changes to the note...

@daira has suggested that it would be good to avoid introducing additional complexity to ZIP 316; instead of adapting UFVKs and UIVKs, for the `zcash_client_backend` APIs we introduce a similar...

> Augment WalletRead::AccountId with the ability to encode to, and parse from, opaque bytes. This encoding MUST NOT be parsed or otherwise interpreted by wallet apps. This doesn't need to...

> However then we need to have two separate types in the crate's public API (the current AccountId, and something else), with a method for converting between them. Right, essentially...