fix(common,frontend): observe ctx in 2 streaming RPCs (GetMempoolStream, GetSubtreeRoots) + GetTreeState hygiene

[dingledropper]

Summary

Follow-up to PR #560 (0b155d5). That PR's sibling-handler audit used a coarse rule — "iterates inline and propagates cancellation through resp.Send errors" — and named six handlers clean against it. Re-auditing the same six handlers under a stricter rule ("ctx must be observable on every blocking op, not only on resp.Send") finds that three of them fail it. This PR fixes two of those three. The third (GetMempoolTx, which combines the same cancel-disrespect with a lock-amplified head-of-line blocking pattern) is under separate disclosure.

The re-audit also identified GetTreeState's SkipHash retry loop as ctx-blind in the same way. In practice that loop terminates in one iteration on the active chain because z_gettreestate (zcashd src/rpc/blockchain.cpp:1411) hard-stops the SkipHash walk at the Sapling activation height, so the GetTreeState change in this PR is a hygiene companion — not a DoS fix — but it mirrors the PR #560 pattern across the rest of the streaming-RPC surface.

Re-audit table

Handler	PR #560 verdict	Re-audit verdict (stricter rule)	Failure mode	Fixed in this PR
GetTaddressBalanceStream	propagates via Send	clean	n/a (single RPC, no loop)	—
GetAddressUtxosStream	propagates via Send	clean	n/a (single RPC + in-mem iterate)	—
GetMempoolStream	propagates via Send	fails	empty-mempool block interval: sendToClient never invoked → cancel signal never observed → handler goroutine survives until next tip	yes
GetSubtreeRoots	propagates via Send	fails	per-subtree common.GetBlock does 2 RPCs each on cache-miss; no ctx between iterations	yes
GetMempoolTx	propagates via Send	fails	s.mutex held across 1 + N sequential RawRequest calls; concurrent callers serialize behind active refresher	under separate disclosure
GetTaddressTransactions	propagates via Send	fails (soft)	inner GetTransaction(ctx, …) silently ignores its ctx parameter; the 30s timeout context constructed at service.go:139 is dead	follow-up PR (code-quality)
GetTreeState	(not in PR #560 audit list)	hygiene-only	per-iteration RawRequest("z_gettreestate") lacks <-ctx.Done() check, but the loop is bounded to 1 iteration in practice by zcashd's activation-height guard at blockchain.cpp:1411	yes (companion, no DoS claim)

Fix

• common/mempool.go: add ctx context.Context as the first parameter of GetMempool(…); replace the inner Time.Sleep(200ms) with select { case <-time.After(200*time.Millisecond): case <-ctx.Done(): return ctx.Err() }; pass ctx.Err() early on the per-iteration top of the loop.
• frontend/service.go GetMempoolStream: pass resp.Context() to common.GetMempool.
• frontend/service.go GetSubtreeRoots: insert if err := resp.Context().Err(); err != nil { return status.FromContextError(err).Err() } at the top of the per-subtree loop body (lines 868-889).
• frontend/service.go GetTreeState: insert the same ctx-check at the top of the SkipHash retry loop body (lines 339-362). Note in code comment that the loop is bounded to one iteration in practice; the check is for symmetry, not for DoS defense.
• frontend/service.go GetLatestTreeState: delegates to GetTreeState; no code change needed beyond what the GetTreeState change above gives transitively.

Test plan

• go build ./...
• go test ./... (existing tests should still pass)
• New regression test TestGetMempoolStreamCancelOnEmptyMempool: launch a regtest stream, cancel its context after 100ms with an empty mempool, assert runtime.NumGoroutine() returns to baseline within one block interval rather than persisting until tip change.

Out-of-scope follow-ups (intentional)

• Thread ctx through common.RawRequest (the btcd rpcclient wrapper). That requires the upstream rpcclient.Client to support RawRequestWithContext, which is a larger surgery. The minimum fix per handler — checking ctx between RPCs — is what this PR does.
• GetSubtreeRoots server-side MaxEntries cap. The MaxEntries proto field documents "0 for all entries" and has no server-side bound; a malicious client can request arbitrarily many subtrees. This is a separate DoS class from cancellation-hygiene and will be filed as its own issue.
• GetTaddressTransactions dead-letter ctx. GetTransaction takes (ctx context.Context, …) but never reads ctx. Will be filed as a small code-quality PR in the next 1-2 weeks.

Notes

• Re-audit framing is intentionally "extending" PR fix(frontend): cancel GetBlockRange producer goroutine on client disconnect #560's audit, not "correcting" it. The coarse rule was correct for the goroutine-leak class PR fix(frontend): cancel GetBlockRange producer goroutine on client disconnect #560 fixed; the stricter rule catches sibling bug classes the coarser rule did not. Two of the six handlers PR fix(frontend): cancel GetBlockRange producer goroutine on client disconnect #560 named clean genuinely are clean under the stricter rule (GetTaddressBalanceStream, GetAddressUtxosStream); three fail it (two fixed here, one under separate disclosure); one is a soft code-quality issue (deferred PR).
• Sibling comparison with Zaino (zaino-state/src/backends/fetch.rs and state.rs) — all four equivalent handlers in Zaino use tokio::spawn + timeout + receiver-closed is_err() checks and do not exhibit any of these classes. Strong corroboration that the lightwalletd patterns are real defects, not intentional design.

AI disclosure

This finding was identified through a re-audit pass, and this PR description and the underlying patches were drafted, with assistance from Claude (Anthropic). I reviewed each step and am the responsible author.