Fix event sequence persistence in stream config state

[pchieneye]

Fix stream event sequence persistence in config state

Summary

This fixes the event sequence persistence bug described in #394.

The root issue was that the sequence counter was persisted separately from the consolidated stream config state, so a future migration that removes legacy per-field storage keys could silently reset the counter and cause previously-used sequence numbers to be re-emitted. That breaks gap detection for consumers that rely on the monotonic event sequence.

This change:

• keeps the event sequence inside the persisted stream state alongside the rest of the config payload
• preserves legacy fallback reads for older streams without the consolidated key
• removes the standalone sequence key during the legacy migration path
• adds a focused regression covering the behavior

Verification

I ran the targeted check:

source $HOME/.cargo/env && cd /workspaces/streamFi-contracts && cargo test -p drip-stream event_sequence_is_persisted_in_config_and_not_left_as_legacy_state -- --nocapture

The build is currently blocked by unrelated, pre-existing compile errors in the stream contract referencing missing enum variants (InvalidRecipient, BackdatedStream, and StreamUnderfunded). Those were left untouched per the task scope.

Closing

Closes #394

[drips-wave]

@pchieneye Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits