Saved connections vault (encrypted DSNs)

[NitinKumar004]

What this adds

A saved-connections vault, so you don't paste a DSN every time. Store a database connection once and reference it by name when creating an operation.

• Encrypted at rest — the DSN is stored with AES-256-GCM (key from MARATHON_SECRET) and is never returned by the API; only name/driver/created-at are exposed.
• Test button — verify a connection actually connects (opens it and pings, with a short timeout) both before saving a draft and for a saved one.
• Tasks reference a connection — a task can carry a connection_id instead of an inline DSN; the DSN is resolved (decrypted) only when a run starts. Works in solo and fleet mode, and for dry-run and quarantine retry.
• Safe delete — a connection in use by a task can't be deleted.

Changes

• internal/secret — AES-256-GCM box (random nonce, tamper-detecting), keyed from MARATHON_SECRET (falls back to a dev passphrase locally). Unit-tested: round-trip, non-determinism, wrong-key and tamper failures.
• connections CRUD + /connections/{id}/test + /connections/test (draft) endpoints.
• Migration 010: tasks.connection_id. Task validation makes the DSN optional when a connection is used.
• Dashboard: a Saved connections manager on the "Connect your system" page (add / test / delete), and a Saved connection vs Enter a DSN picker in the new-operation wizard (defaults to a saved connection when you have one).

How to test

1. Open Connect your system, add a connection (Postgres or MySQL), hit Test — it should say connected.
2. Create a new operation; in step 2 pick your saved connection instead of a DSN.
3. Start it — the run resolves the DSN from the encrypted connection and backfills normally.

Screenshots

Captured with headless Chrome.

Saved connections vault

New-operation wizard — pick a saved connection

Notes

• Set MARATHON_SECRET in production so stored DSNs are protected by your own key. Without it, a fixed dev passphrase is used (fine for local, not for production).