Phase 2: maintenance tracking and alert engine

[faborubio]

Summary

Adds maintenance/compliance tracking and a proactive alert engine on top of the Phase 1 fleet core.

Data model

• ServiceRecord — logged maintenance (category, date, odometer, cost, vendor).
• MaintenanceSchedule — recurring rules per vehicle (every N months and/or N miles) that compute next_due_on / next_due_odometer.
• Renewal — document expiry (insurance, registration, inspection).
• Alert — polymorphic (alertable) with category, severity and status enums.

Alert engine

• Alerts::Scanner reconciles an account's alerts idempotently: creates an alert when a condition holds, updates it in place when the underlying date changes, swaps due_soon → expired over time, and dismisses it once the condition clears. Covers overdue/expiring renewals, due maintenance (time or mileage), and expiring driver licenses.
• Alerts::Dispatcher emails opted-in users a digest and marks pending alerts as sent so they aren't re-emailed.
• ScanAllAlertsJob fans out one AccountAlertsJob per account; scheduled daily via Solid Queue recurring tasks (config/recurring.yml).

UI & notifications

• Maintenance CRUD nested under vehicles, surfaced as sections on the vehicle page (renewals, schedules with due badges, service history).
• Alerts index, a live nav badge, and Turbo Stream dismiss.
• AlertsMailer digest (HTML + text) with a working mailer preview.
• Logging a service auto-updates the matching schedule's last-performed markers.

Test plan

• 129 RSpec examples green (models, scanner idempotency/reconciliation, dispatcher, mailer, jobs, request + system specs)
• RuboCop, Brakeman, bundler-audit, importmap audit clean
• db:seed now generates renewals, service history and ~55 open alerts for a lively demo
• CI green on this PR

🤖 Generated with Claude Code