feat(scanning): scheduled scans (cron-like) (#7)

[Metbcy]

Summary

Implements #7: scheduled scans (cron-like recurring runs).

What's new

Backend

• Migration 006_add_schedules_table.py adds two tables:
  • schedules (id, name, target_path, scan_types, cron_expression, last_run, enabled, created_at)
  • schedule_runs (id, schedule_id, scan_id, triggered_at) with index on (schedule_id, triggered_at DESC)
• scheduler.py — SchedulerService over APScheduler AsyncIOScheduler. Jobs registered from enabled DB rows at startup; reschedule/remove/add keep the live scheduler in sync with API mutations.
• Multi-worker safety: _fire_schedule() uses a Redis SET NX EX lock (via the pubsub backplane from feat(infra): multi-worker uvicorn via Redis pubsub backplane #4) keyed on schedule:<id>:<minute_bucket> so two workers never fire the same trigger. Falls back to single-process when SECURESCAN_REDIS_URL is unset.
• api/schedules.py — POST/GET/PATCH/DELETE /api/v1/schedules and GET /{id}/runs. Admin scope. Cron expressions validated at 422 via CronTrigger.from_crontab.
• apscheduler>=3.10.0 added to pyproject.toml.

Frontend

• /settings/schedules page mirrors the keys/webhooks layout: DataTable, create/edit modal, delete confirm, schedule run-history drawer.
• New Schedule / ScheduleRun types and CRUD helpers in lib/api.ts.
• Sidebar nav entry.

Docs

• docs/src/scanning/scheduled-scans.md.

Tests

• 18 new tests pass, 1 skipped (Redis cross-worker double-fire test, gated on SECURESCAN_REDIS_URL exactly like the pubsub redis test).
• Mocked APScheduler trigger creates a real Scan and a schedule_runs row.
• Local: cd backend && ruff check . && ruff format --check . && python -m pytest tests/ -x -q — 950 passed, 4 skipped (pre-existing nmap/semgrep env-only failures excluded; same as main).

Notes

• Defaults are off; admin opts in by creating a schedule.
• Cron parser is APScheduler's, which accepts the standard 5-field crontab.
• Lock TTL is 60s, scoped to the minute bucket so a slow worker never blocks a later trigger.