Add dismiss violations functionality

Allow users to dismiss violations they've reviewed and decided are not actionable — false positives, accepted technical debt, or intentional patterns.

## What needs to be done

### Backend

**New status: `dismissed`**
- Add `dismissed` as a valid violation status alongside `new`, `unchanged`, `resolved`
- Applies to both architecture violations (`violations` table) and code violations (`code_violations` table)

**API endpoints:**
- `POST /api/repos/:id/violations/:violationId/dismiss` — dismiss an architecture violation
- `POST /api/repos/:id/code-violations/:violationId/dismiss` — dismiss a code violation
- Optional: accept a `reason` field (e.g., "false positive", "accepted risk", "by design")
- Dismissed violations should persist across analyses — when a violation is carried forward as `unchanged`, check if the previous version was dismissed and carry the dismissal forward

**Lifecycle handling:**
- Dismissed violations should NOT appear in the default violations list (filter `status IN ('new', 'unchanged')` already excludes them)
- Add a `?status=dismissed` query parameter to show dismissed violations
- When a dismissed violation is detected again in a new analysis, keep it dismissed (don't reset to `new`)
- If the underlying code changes and the violation is re-detected with different content, reset to `new`

### Frontend

**Violations panel:**
- Add a dismiss button (X icon or "Dismiss" action) on each violation card
- Show a small confirmation or allow entering a reason
- Dismissed violations disappear from the default view
- Add a filter/toggle to show dismissed violations (grayed out)

**Analytics:**
- Dismissed violations should not count in severity charts
- Optionally show a "dismissed" count separately

### CLI
- `truecourse list` should exclude dismissed violations by default
- `truecourse list --all` or `truecourse list --dismissed` to include them

### Schema changes
- May need a `dismissed_at` timestamp and `dismissed_reason` text column on both violation tables
- Generate migration via `pnpm db:generate`

Start by locating the violations and code_violations tables, their analysis lifecycle, the listed API endpoints, the Violations panel, and the truecourse list command. Run pnpm db:generate for the schema migration, then trace how statuses and filters flow through backend, frontend, analytics, and CLI code. Done means dismissed items persist correctly, are excluded by default, and can be viewed and filtered explicitly.

Written by the indexing model from the issue text.