Write unit tests for ActivityRepository optimistic insert

The main challenge is that `emitsInOrder` requires the stream to behave deterministically. Since the local ID is generated at call time using UUID, use `startsWith('local_')` in a predicate matcher rather than an exact string. For the second emission on the success path, the server record's ID is controlled by the mock — use a fixed test ID like 'server-id-abc123' for predictable assertions. For async stream testing, it is important that the mock's `insertActivity` call completes in a future microtask, not synchronously — if it resolves synchronously the stream may already have both items when `expectLater` is called, which is fine, but if the implementation relies on an async gap between emissions, ensure the mock uses `Future.microtask` or `Future.delayed(Duration.zero)`.

Document whether `SyncStatus.failed` retains the local ID or uses null — the test must match the implementation contract, and the contract must be documented in the repository's method doc comment.

Unit tests using flutter_test and mocktail. The critical testing pattern is `await expectLater(repository.insertActivity(draft), emitsInOrder([predicate1, predicate2, emitsDone]))`. Use `predicate` matchers (e.g., `predicate((r) => r.id.startsWith('local_') && r.syncStatus == SyncStatus.pending)`) rather than equality matchers since the local UUID is non-deterministic. For the async stream test to work correctly, the mock client's insertActivity must complete asynchronously — use `thenAnswer((_) async => serverRecord)` with a real async gap.

Use `TestWidgetsFlutterBinding.ensureInitialized()` if any platform channels are involved. Organize all tests under `group('ActivityRepository', ...)` with nested groups for `insertActivity`, `getActivities`, and `deleteActivity`.