Implement coordinator-level forced resolution in DeduplicationQueueService

Define a `ResolutionAction` enum in the domain layer: `enum ResolutionAction { keepBoth, keepFirst, keepSecond, merge }`. The repository method signature should be `Future resolveQueuePair(String pairId, ResolutionAction action, String coordinatorId, DateTime resolvedAt)`. For KEEP_FIRST and KEEP_SECOND, a second repository call updates the activities table — consider wrapping both calls in a Supabase RPC function to get transaction guarantees (Dart client doesn't support multi-statement transactions natively). For MERGE, gate behind a feature flag or throw `UnimplementedError('MERGE action requires MergeActivityService — implement in a later task')` to prevent silent data loss.

After any successful write, call `ref.invalidate(unresolvedCountProvider)` to immediately refresh the nav badge. Emit a `PairResolvedEvent` on a Riverpod event bus so the queue list BLoC can remove the resolved pair from its local state without re-fetching.

Unit tests: mock the repository and verify each ResolutionAction produces the correct sequence of repository calls. Test that KEEP_FIRST marks activity_b as duplicate and not activity_a. Test ChapterScopeException thrown for out-of-scope pairs. Test PairAlreadyResolvedException for already-resolved pairs.

Test cache invalidation is called on success. Test that failure in the second write (activity update) is handled gracefully with a descriptive error. Integration tests: execute forceResolve() against a test Supabase instance and verify row states. Test concurrent resolution of the same pair returns an error for the second caller.