Implement Duplicate Resolution Handler

Use a Supabase RPC (Postgres function) for the REPLACE path to ensure atomicity — DELETE + INSERT in a single server-side transaction is safer than two sequential client calls. The duplicate-reviewed-flag should be a boolean column 'duplicate_reviewed' on the activity table, defaulting to false, set to true server-side inside the RPC for KEEP_BOTH and REPLACE. The CANCEL path is entirely client-side: emit the audit event via a separate lightweight Supabase insert, then signal the BLoC to transition to 'cancelled' state — no activity row is created. Model ResolutionResult as a Dart sealed class for exhaustive pattern matching in the BLoC.

Register via Riverpod and ensure it is disposed with the BLoC. For audit events, reuse the claim_event table structure (actor_id, actor_role, from_status, to_status) with an additional resolution_type field.

Unit tests: test each resolution path (KEEP_BOTH, CANCEL, REPLACE) with mocked repositories. Test REPLACE rolls back new activity insert if candidate delete fails. Test that the duplicate-reviewed-flag is correctly set on KEEP_BOTH path. Test REPLACE with already-deleted candidate returns ErrorResult without throwing.

Test audit event shape matches required schema for all three paths. Integration tests: verify REPLACE atomicity — run against a real Supabase test instance and confirm no partial writes. Verify cross-organization deletion is blocked by RLS. Confirm audit log entries are created for all resolution types.

Achieve 90% branch coverage for the handler.