fix(aztec-nr): tolerate malformed partial-note completion logs

[nchamo]

Problem

Partial-note discovery has four crash points on the completion path, each reachable by a malicious sender and each firing before the pending note advances — so every subsequent sync re-hits it and permanently freezes note sync for that contract:

• a matched completion log yields no note (panic),
• a pending note resolves to more than one completion log (assert),
• the delivered private half plus the log's public content exceed the packed-note capacity (BoundedVec overflow in the append), or
• the completion log payload is empty, so reading the storage slot is out of bounds.

The first three are reachable on the canonical token (mismatched content over the unconstrained delivery channel, completing the same partial note twice which the token does not prevent, and an over-length delivered private half); the last needs an attacker-controlled contract emitting a tag-only log.

Fix

Make each non-fatal: warn and advance the FSM rather than panicking, so one bad message cannot break sync. A completion log that cannot yield a note (empty, over-length, or matching none) is skipped; more than one completion log completes with the first.

Fixes F-798

[nventuro]

I don't think (current) partial notes can be completed more than once. And the meaning of 'crafted' is unclear here.

[nchamo]

I think we can, I could reproduce the issue with discovery_tolerates_a_partial_note_completed_twice. And I re-worded the comments to avoid "crafted"

[nchamo]

@nventuro , I added handling for two more panic sources. I updated the PR description to list all of them. Some of them are hard to trigger, some of them are easier. But I think it makes sense to be on the defensive side of things and just avoid panics all together, instead of trusting the contract dev to protect themselves against these situations