fix: ecdsa background tasks should be infallible

[gilcu3]

Closes #2122

I took the chance to fix triple generation as well.

[claude]

Code Review

Clean, correct change. Making background triple/presignature generation tasks infallible is the right approach -- these are infinite loops spawned into tracking::spawn, and having them return anyhow::Result was misleading since the ? on new_channel_for_task would silently kill the entire background generation loop on a transient channel error. Now errors are logged and the loop continues, which is the correct resilience behavior for background tasks.

Minor non-blocking observations:

1. In triple.rs:120, participants.clone() is unnecessary since participants is not used after the match. The original code passed participants by value. Not worth a follow-up.

2. In presign.rs, when new_channel_for_task fails after triple_store.take_owned().await (line 101), the consumed triples are lost -- but this is strictly better than the old behavior where the ? would also lose the triples AND kill the entire presignature generation loop permanently.

Approved.

[gilcu3]

@claude review

In presign.rs, when new_channel_for_task fails after triple_store.take_owned().await (line 101), the consumed triples are lost -- but this is strictly better than the old behavior where the ? would also lose the triples AND kill the entire presignature generation loop permanently.

you are right about this, might be something worth thinking about in the future

[claude]

No critical issues found beyond what the previous review already identified. The change correctly converts infinite background loops from fallible to infallible, preventing transient channel errors from permanently killing triple/presignature generation. Error handling via continue is the right resilience pattern here.

✅ Approved

[DSharifi]

Given that this was an error we exited on earlier, how severe is it? Should it be an error log instead?

[gilcu3]

I think as we are continuing execution anyway, a warning is more appropriate.

On a more general note, if we begin really seeing this in the logs a full revamp might be necessary here, as technically it should be a pretty infrequent behavior

[netrome]

Generally speaking we should not use Error logs unless something unexpected happens imo. Network connection drops are expected during normal operations and should therefore be warnings as I see it.

[DSharifi]

Thanks!

[kevindeforth]

nice, thank you!