Revision history: change sets, revisions, and revert (#48)

The undo substrate. The agent is going to act freely — "empty the garlic bed and
plant cucumbers" runs without a confirmation prompt — and that is only a
defensible default if the result is easy to roll back. So undo lands before the
agent write path, not after it.

The unit of undo is the OPERATION, not the row. A change set groups the
row-level revisions it produced; revert replays their inverses. Emptying a bed
and replanting it touches one object and many plantings, and undoing half of
that is worse than useless.

Two properties shape the rest:

Revert is itself a change set (reverts_id names its target), so history is
append-only and an undo can be undone. git revert, not git reset.

Revert is version-guarded per entity. Every snapshot carries the row's version;
if something edited that row after the change set being reverted, restoring the
old snapshot would silently discard the newer edit, so it is reported as a
conflict and left alone while the rest of the change set still reverts.

The auto-scope is what keeps this invasive but shallow. Service mutations call
record(), which joins the change set on the context if one is open and otherwise
opens a single-op one on the spot. REST handlers needed no edits at all and
every UI mutation lands in history for free; only the agent wraps a whole turn.
Multi-row operations (FillRegion, ClearObject) pass all their changes in one
record call, so a 12-plop fill is one change set with 12 revisions and one undo.

Revisions are buffered and written with their change set in a single
transaction, so an operation that fails partway leaves no half-recorded history.
Recording is best-effort after the fact: the row is already written, so failing
the caller there would report a failure that didn't happen and invite a
duplicate retry. A gap is logged loudly instead.

Two sharp edges handled explicitly rather than by luck:

Deleting an object cascades its plantings away at the FK level, where the
service never sees them. deleteObjectRecording snapshots them first, or the
delete would be listed in history and not actually be undoable.

Restoring deleted rows reuses their ids, and a restored plop needs its object
back first. planRevert runs three explicit passes — restore parents then
children, then updates, then delete created children before their parents —
instead of trusting reverse-seq ordering to happen to be right.

Garden deletion stays out of scope, as designed: the cascade is invisible to the
service and ON DELETE CASCADE would take the history with it. The history UI
will say so rather than pretend otherwise.

Closes #48

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ

DESIGN.md

@@ -22,6 +22,7 @@ SQLite, centimeters everywhere (display-side imperial conversion only), `version
 - **garden_shares** — (garden_id, user_id) unique, role `viewer`|`editor`, created_by. Owner is implicit via `gardens.owner_id`, never a share row.
 - **garden_objects** — one polymorphic table: `kind` (`bed`|`grow_bag`|`container`|`in_ground`|`tree`|`path`|`structure`), name, `shape` (`rect`|`circle`; `polygon` + `points` JSON reserved in schema, not in the v1 editor), center `x_cm`,`y_cm` in garden space, `width_cm`,`height_cm` (circle: width=diameter), `rotation_deg`, `z_index`, `plantable` bool, nullable `color` override, `props` JSON for kind-specific extras (bed height, tree species…), notes.
 - **plants** — catalog. `owner_id NULL` = built-in (~30 seeded via migration, read-only, clone to customize). name, category (`vegetable`|`herb`|`flower`|`fruit`|`tree_shrub`|`cover`), `spacing_cm` (mature spacing), `color` hex, `icon` (emoji string — zero assets in v1), nullable `days_to_maturity`, notes. Users see built-ins + their own.
+- **change_sets** / **revisions** — the undo substrate. A change set groups the row-level revisions one logical operation produced (`source` ui/agent/api, `summary`, nullable `agent_run_id`, nullable `reverts_id`); a revision is `(entity_type, entity_id, op, before, after)` with full JSON row snapshots. The unit of undo is the **operation, not the row**. Revert is itself a change set, so an undo can be undone; it is version-guarded per entity and reports conflicts rather than clobbering a later edit. Garden *deletion* is deliberately not revertible (the cascade is invisible to the service, and would take the history with it).
 - **plantings** ("plops") — object_id, plant_id, center `x_cm`,`y_cm` **in the parent object's local frame** (moving/rotating a bed moves its plants for free), `radius_cm` (a plop is a circular patch), nullable `count` (NULL = derived: `max(1, round(π·r² / spacing_cm²))`), nullable label, `planted_at`/`removed_at` dates. "Clear bed" sets `removed_at`; v1 shows rows where `removed_at IS NULL`. Year-over-year history and a future plan/scenario layer build on these dates without schema surgery.
 
 ## Geometry
@@ -52,6 +53,8 @@ POST /auth/register | /auth/login | /auth/logout     GET /auth/me      GET /auth
 GET  /auth/oidc/login      GET /auth/oidc/callback   (authorization-code + PKCE)
 GET,POST /gardens                                    GET,PATCH,DELETE /gardens/:id
 GET  /gardens/:id/full        ← one-shot editor load: garden + objects + plantings + referenced plants
+GET  /gardens/:id/history     ← change sets, newest first (paginated)
+POST /change-sets/:id/revert  ← undo an operation; 201, or 409 + the conflicts it skipped
 POST /gardens/:id/copy        ← deep-copy a garden you own (objects + active plops; not shares/link)
 POST /gardens/:id/objects     PATCH,DELETE /objects/:id
 POST /objects/:id/plantings   PATCH,DELETE /plantings/:id
@@ -76,7 +79,8 @@ internal/store/          sqlite.go (open/pragmas), migrate.go, migrations/*.sql
 internal/domain/         plain structs + sentinel errors (ErrNotFound, ErrForbidden,
                          ErrVersionConflict)
 internal/service/        ★ THE SEAM. All permission checks + business ops. auth.go, gardens.go,
-                         objects.go, plantings.go, plants.go, shares.go, ops.go (FillRegion etc.)
+                         objects.go, plantings.go, plants.go, shares.go, ops.go (FillRegion etc.),
+                         revisions.go (change-set scoping, recording, revert)
 internal/api/            thin gin handlers (decode → service → encode), session middleware,
                          ginserver setup, routes.go, oidc.go, spa.go (embed fallback)
 internal/webdist/        dist.go: //go:embed all:dist   (web build copied in by Makefile)
@@ -85,6 +89,8 @@ web/                     Vite app
 Makefile                 (cd web && npm run build) → copy dist → CGO_ENABLED=0 go build
 ```
 
+**Every mutation is recorded.** Service mutations call `record(...)`, which joins the change set on the context if one is open and otherwise opens a single-op one for that mutation alone. That auto-scope is what keeps undo shallow: REST handlers need no changes at all, and only the agent wraps a whole turn (`WithChangeSet`) so a multi-step turn undoes as one unit. A multi-row operation passes all its changes in one `record` call for the same reason.
+
 **The service seam is the point.** Every operation is a method on `*service.Service` taking `(ctx, actorUserID, args)`; all ACL checks live there, not in handlers. REST handlers are thin adapters; future agent tools are equally thin `llm.DefineTool[Args]` adapters over the same methods — so agent calls inherit permission enforcement for free. Bulk ops designed for agents from the start, e.g. `FillRegion(ctx, actor, objectID, region, plantID, spacingOverride)` with `region` a rect/circle in object-local coordinates.
 
 ### Auth