Bound the foreign-key shielded note scan (unbounded genesis-to-tip scan on hostile unfunded invitation keys)

[bfoss765]

Problem

scan_notes_for_foreign_key (packages/rs-platform-wallet/src/wallet/shielded/sync.rs:826 at PR #4204 head 10514c366) — the L2-invitation claim path's transient scan — streams the on-chain shielded note set from position 0 with no cap (sync_shielded_notes_stream(sdk, &prepared, 0, None)). The only early exit is value coverage (total >= stop_at_value), which a syntactically valid but unfunded invitation key never triggers: one hostile invite forces a genesis-to-tip proof-verify + trial-decrypt scan of the complete shielded history.

The caller's birth-height hint cannot bound this today and is advisory-only (logged at operations.rs:1637): shielded notes are indexed by tree position and the tree exposes no height→position oracle — a chunk's block_height is the proof-tip height, not a per-note inclusion height — so the hint cannot seed the scan start.

Raised as a review suggestion on #4204: #4204 (comment)

Chosen direction

Authenticated funding position carried in the invite payload — a wire-format change to the invitation, which should ride the #4301 two-note invite format change (the natural vehicle for revising the invite payload).

A local scan budget was considered and rejected as the primary fix: a mis-sized bound turns a deep-funded legitimate invite unclaimable, and a caller-supplied birth height is attacker-controlled, so neither bounds hostile input soundly. (A resumable per-attempt scan budget with a typed "budget exhausted, resume to continue" outcome remains a possible interim guard if one is wanted before the wire-format change lands.)

Interim exposure

Bounded operationally rather than in-protocol for now:

• The claim scan is invitee-initiated — an attacker with a hostile invite burns the accepting device's bandwidth/CPU, not the network's.
• The Kotlin host surfaces the claim as a cancellable long-running operation, so a runaway scan is user-abortable.

References

• PR feat(kotlin-sdk): one-time Orchard key shielded-invite API (inviter + claim) #4204 (shielded invites) — origin of the finding
• PR feat(platform-wallet): multi-output shielded transfers + output-aware fee predictor (two-note invites) #4301 (two-note invites) — the wire-format change the authenticated funding position should ride

[bfoss765]

Implemented in #4313 at 78e59695ef (the claim scan lives on that branch): each claim attempt now consumes at most FOREIGN_SCAN_BATCH_BUDGET = 128 stream batches (≥ ~260k trial decryptions), then pauses with the retryable typed ShieldedForeignScanBudgetExhausted { scanned_through } — progress is checkpointed, so attempts compound instead of restarting, and a hostile unfunded key costs bounded work per attempt no matter what the link claims. Surfaced as FFI code 44 → Kotlin ShieldedScanBudgetExhausted (isRetryable = true).

The birth-height (bh) floor considered here is not implementable at this layer — the commitment tree has no height→position oracle (a chunk's block_height is the proof-tip height, not per-note inclusion), and the hint is attacker-controlled anyway, so the budget carries the whole bound.

Unit-tested stream-generically (pause-checkpoint-resume, the partial-batch end-of-stream exemption, error-path checkpointing). This issue can close when #4313 merges.