Implement ScenarioRuleRepository data layer

Follow the existing repository pattern in the codebase — examine other repository classes (e.g. activity repository or contact repository) for consistent structure before implementing. Place model classes in `lib/features/scenario_rules/data/models/` and the repository in `lib/features/scenario_rules/data/repositories/`. Use `freezed` and `json_serializable` if the codebase already uses them for model generation — do not introduce a new serialization pattern.

Define a `ScenarioRuleRepositoryProvider` using Riverpod's `Provider` or `StateNotifierProvider` following the established pattern. For error handling, wrap all Supabase calls in try/catch and rethrow as domain-specific exceptions. The TriggerCondition class likely needs to handle multiple trigger types (e.g. inactivity duration, event type) — design it as a sealed class or use a type discriminator field in JSON.

Ensure toJson produces snake_case keys matching the database column names.

Unit tests using flutter_test and a mocked SupabaseClient: (1) fetchRulesForChapter returns a List when the mock returns valid JSON; (2) fetchRulesForChapter returns an empty list when no rules exist; (3) fetchRuleById returns null when ruleId not found; (4) fetchRuleById returns a ScenarioRule when found; (5) upsertRule calls the correct Supabase upsert method with the serialized rule; (6) deleteRule calls delete with the correct ruleId filter; (7) fromJson correctly deserializes all fields including nested TriggerCondition; (8) fromJson handles missing optional fields without throwing; (9) repository throws ScenarioRuleRepositoryException when Supabase returns an error response. Integration tests (against local Supabase): (10) fetchRulesForChapter with seeded data returns only chapter-scoped rules; (11) cross-chapter read returns empty list due to RLS.