feat: Support Postgres-backed baseline storage (with audit trail) as an alternative to the local baseline file

[Tgenz1213]

Problem

#68 scopes baseline mode to a local file (.archguard/baseline.json), with an open question about whether that file should be committed or gitignored. Teams already centralizing their ADR index in Postgres via vector_store.connection_string/ARCHGUARD_DB_URL (internal/index/pgvector.go, PgStore) have the same sharing problem for baseline state that PgStore already solves for the index: multiple CI runners and contributors need to see the same accepted-violations state without relying on a single committed file in one branch.

Unlike the embeddings index, which is a derived, disposable cache safe to centralize with no history (PgStore.CalculateHash is a hardcoded "remote" constant, per CLAUDE.md), a baseline entry is a decision — someone judged a specific violation acceptable for now. That's closer in kind to an ADR (also a decision, deliberately kept in git as reviewable markdown) than to the embeddings cache. A DB-backed baseline needs its own record of who made that call and why, or it becomes a silent, unreviewed suppression mechanism.

Acceptance Criteria

• When vector_store.connection_string/ARCHGUARD_DB_URL is set, baseline entries can optionally be stored in Postgres instead of (or in addition to — TBD during implementation) the local file from Add a baseline mode to grandfather pre-existing violations on adoption #68, scoped by project_name the same way archguard_adrs already is.
• The baseline table includes an audit trail per entry: at minimum who/what accepted the violation (e.g. CI actor, or a required --reason string passed by the person running --update-baseline) and when. This is the part that doesn't exist in Add a baseline mode to grandfather pre-existing violations on adoption #68's file-based design and is the actual point of this issue, not just "the same data in a different store."
• Reads/writes go through the same VectorStore-style connection already configured for the index — this should not introduce a second, separate DB connection string as its own config knob.
• Behavior when DB-backed baseline is enabled but the DB is unreachable is defined explicitly (fail the run vs. fall back to file vs. fail open) — this is a live design question, not assumed.
• README documents the tradeoff explicitly: file-based baseline requires no infrastructure and is git-reviewable; DB-backed baseline requires the same Postgres setup as PgStore and centralizes state across branches/runners at the cost of losing git as the review mechanism (mitigated by the audit columns above).

Related

Depends on #68 (file-based baseline ships first; this extends it with a second storage backend, not a replacement).