fix(discovery): restore cursor after boundary finding

[Gaijin-01]

Summary

Set cursor.last_note_index = Some(boundary) after bisection completes in find_last_note_index(), so that the next discover_notes_paginated() call resumes linear scan from the correct position instead of re-scanning already-filtered notes from the beginning.

Root cause

find_last_note_index() persisted total_n_notes via bisection but omitted the corresponding last_note_index assignment. On the next discover_notes_paginated() call, cursor.start_index() returned 0, causing already-filtered notes to be re-scanned — wasting IO budget and leaking access patterns via repeated RPC calls to the same note indices.

Solution

Add cursor.last_note_index = Some(boundary) after bisection completes. On the next call, start_index() = boundary + 1, resuming linear scan at the correct position without re-probing already-filtered notes.

Validation

• Added regression test test_find_last_note_index_sets_cursor_last_note_index.
• 156 tests pass, 7/7 runs stable.
• No changes to Cairo contracts or SDK.

Scope

• Changes limited to crates/discovery-core/src/discovery/last_note_index.rs.
• No changes to Cairo contracts, SDK, or discovery service API.

References

• Issue: (none referenced)
• Upstream file(s): crates/discovery-core/src/discovery/last_note_index.rs
• Related PR(s): fix(discovery): consume budget only for registered recipient addresses #899, fix(discovery): add compute_call_set_hash for SNIP-12 additional_data support #902, fix(sub_account): reject duplicate tokens in collect_open_notes #903

---

This change is