Review clippy suppressions added in warning cleanup

[affandar]

Summary

During the recent clippy warning cleanup (commit b3669cf), we added module-level and function-level #[allow(...)] suppressions to eliminate warnings. While these suppressions are justified for the current codebase, they should be periodically reevaluated to ensure they're still necessary.

Suppressions Added

Module-level suppressions

The following files have #![allow(clippy::expect_used)], #![allow(clippy::unwrap_used)], and #![allow(clippy::clone_on_ref_ptr)]:

File	Justification
src/lib.rs	Mutex locks - poison indicates panic, should propagate
src/futures.rs	Mutex locks for orchestration context
src/runtime/mod.rs	Mutex locks throughout runtime
src/runtime/registry.rs	Mutex locks for handler registries
src/runtime/execution.rs	Mutex locks in execution engine
src/runtime/replay_engine.rs	Mutex locks in replay engine
src/runtime/observability.rs	Mutex locks for metrics
src/runtime/test_hooks.rs	Test code - unwrap is acceptable
src/runtime/dispatchers/orchestration.rs	Mutex locks in dispatcher
src/runtime/dispatchers/worker.rs	Mutex locks in worker dispatcher
src/providers/sqlite.rs	Mutex/lock operations

Function-level suppressions

Suppression	Location	Justification
too_many_arguments	ActivityContext::new	Legitimate parameters for context construction
too_many_arguments	ActivityContext::new_with_cancellation	Same as above
too_many_arguments	run_single_execution_atomic	Atomic execution requires all parameters
too_many_arguments	ack_orchestration_with_changes	Complex ack operation
too_many_arguments	Provider trait	Trait methods have inherent complexity
type_complexity	run_turn_with_status_and_cancellations	Complex return type is intentional

Rationale for Current Suppressions

1. expect_used/unwrap_used on Mutex locks: Mutex poisoning indicates a panic occurred in another thread while holding the lock. This is a critical error and should propagate as a panic rather than being handled gracefully.

2. clone_on_ref_ptr: Arc::clone() vs .clone() is a style preference. We use .clone() for brevity.

3. too_many_arguments: Some functions genuinely need many parameters. Refactoring to use builder patterns or config structs may be considered but isn't always cleaner.

Future Considerations

• Evaluate if some expect()/unwrap() calls could be replaced with ? operator
• Consider if clone_on_ref_ptr should be enforced for clarity
• Evaluate builder patterns for functions with many arguments
• Review if any suppressions can be narrowed to specific lines instead of module-level