Fix repo update silently dropping agent_cli; single-source the domain→row column mapping

[tildesrc]

PATCH /repos/{id} with a new agent_cli reported success but never persisted it — an existing repo could never be switched to codex, and the dashboard's repo-edit reverted on the next refresh.

Root cause

_update_repo hand-copied ten columns onto the loaded row and omitted agent_cli. Insert was fine (_RepoRow.from_domain carried the field), so only the update path lost it — introduced by #384, unnoticed until the dashboard grew the CLI picker. Store.update_repo documents itself as "a full-row write … the store just overwrites the row", so this was a contract violation.

Two things hid it:

• TaskService.update_repo returns its in-memory merge rather than a re-read, so the API response cheerfully reported the value that was never stored.
• test_repo_agent_cli_defaults_and_round_trips_over_rest looked like coverage but asserted only the PATCH response body, never re-reading. It passed against a row that still said codex.

The fix

Each row class now states its domain→column mapping once, in column_values, which both the insert (from_domain) and the update (_apply_columns) go through — so a newly added column can't be carried on create and silently dropped on update. One line would have fixed agent_cli; this fixes the class of bug.

_update_task had the identical hand-copied shape and was dropping memo, initial_prompt, starting_model and agent_cli from save_task — the same shared mapping fixes it. History stays append-only: it's a relationship, not a column, so column_values never touches it.

Tests

The store contract tests already had a reflective guard proving a created repo/task round-trips with every field intact — but nothing equivalent for the update path, which is exactly the hole this bug fell through. Added it for both, with _assert_every_field_changed forcing the mutation fixture to move every new field so the round-trip genuinely exercises it (a new field is guarded by default). Also tightened the false-positive REST test to assert the re-read.

All five new/tightened assertions were confirmed to fail before the fix, on both store backends.

No migration — the columns were always correct.

Plan: the task's plan.md artifact.