Implement inactivity window evaluation in trigger engine

The boundary condition for 'inactive' should be: `daysSinceLastActivity > config.inactivityWindowDays` (strictly greater than, not >=). This prevents triggering on the exact day the threshold is met, giving the mentor one full day buffer. For the batch case where the engine evaluates all mentors in an organization, use a single SQL query: `SELECT peer_mentor_id, MAX(date) as last_active FROM activity WHERE organization_id = $1 GROUP BY peer_mentor_id` — then join with assignment statuses in the same query to filter paused mentors. This reduces N+1 database calls to a single round trip.

Keep the evaluator function pure (no side effects) — this is critical for the architecture because it allows the engine to evaluate all scenarios for all users and then batch-dispatch decisions in one pass, rather than interleaving evaluation and dispatch. Use UTC timestamps throughout — Norwegian users are in CET/CEST (UTC+1/+2), but inactivity windows should be based on elapsed wall-clock days relative to the server's UTC clock.

Unit tests with mocked repositories and preference service: test that a user whose last activity is exactly at the threshold boundary (equal to inactivityWindowDays) does NOT trigger (boundary condition — inactive means strictly greater than); test user with activity 1 day beyond threshold triggers; test that opted-out user with stale activity returns shouldTrigger=false; test that a user within cooldown returns shouldTrigger=false even if inactive; test that a paused mentor returns shouldTrigger=false; test new user with no activity record returns a trigger decision (not an exception). Integration test: insert activity rows in test DB, invoke evaluator, assert correct trigger decisions. Verify the SQL aggregation query plan uses an index via EXPLAIN.