fix(zakura): avoid no-op sequencer view wakeups

[evan-forbes]

Motivation

Split out of #435.

Under sustained byte-budget backpressure, the sequencer could publish an otherwise-identical SequencerView after a no-op control input. Because watch::send_replace wakes watchers even when no scheduling field changed, a peer routine waiting on sequencer_view.changed() could wake, retry refill, request floor funding again, and immediately repeat. On a real clock this wastes CPU and can starve progress under load; under start_paused it can wedge because Tokio virtual time only advances when every task parks.

Solution

• Derive PartialEq for SequencerView.
• Replace unconditional view wakeups with send_if_modified.
• Add view_schedulable_ne so throughput-rate-only refreshes update the stored view but do not wake the reactor or peer routines.
• Add sequencer_view_rate_refresh_does_not_wake_watchers, a deterministic focused test that checks rate-only refreshes do not notify while schedulable changes still notify.
• Add the changelog entry for the busy-spin fix.

Validation

• cargo fmt --all -- --check
• cargo test -p zebra-network sequencer_view_rate_refresh_does_not_wake_watchers

AI Disclosure

Used Codex to split #435 into focused branches/PRs, add the focused deterministic test, and run the targeted validation above.