fix: try every completion log when completing a partial note

[vezenovm]

step_pending only ever tried completion_logs.get(0), and completion marked the FSM completed whether or not that log discovered anything. The completion log tag is not unique, so a log yielding no note sitting ahead of the genuine completion permanently consumed it. The note was silently lost.

Every fetched log is now tried in turn, and the first that yields a note completes the reception. If none does, the reception still advances on the first log, preserving #24668's property that a poisoned delivery cannot keep it re-running nonce discovery on every sync.

Red/green

step_discovers_the_note_when_an_earlier_completion_log_yields_none fails on next: enqueued_note_count() is 0, expected 1, while the FSM still reaches is_completed.

Green after the fix: partial_notes::fsm 15/15, token_contract test::transfer_to_private 8/8 (including #24668's discovery_tolerates_a_partial_note_completed_twice).

Known gap

A genuine completion mined after a non-discovering log is still lost if a sync lands between the two blocks. Every fetch returns the tag's full history (LogRetrievalRequest::new leaves from_block unset), so it only bites in that window.

Closing it needs the reception to stay pending when nothing discovers, which is only safe once it has a TTL. Delivery is unconstrained, so anyone can otherwise spam bogus partial notes that never leave Pending and cost a full nonce-discovery pass every sync. The sibling offchain-reception FSM already does this (messages/processing/offchain/reception.nr:242). Tracked in F-828.