feat(ui): name snapshots, and put fork, rename and delete on their mark - #2847

kagent-dev/kagent#2847 renamed the chat's checkpoint to "Snapshot", gave
it a generated name, and moved Fork, Rename and Delete onto the snapshot's
mark. The refreshed capture in this PR shows that card; the prose still
described the old Checkpoint/Fork/Remove strip, and the alt text promised
a tool call that the taller card pushed out of frame.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Signed-off-by: Rachael Graham <[email protected]>

Kagent 1.0 recorded core version 1 with an earlier 000001 baseline, and
000001 has since changed in place (upstream kagent-dev#2847, kagent-dev#2857, kagent-dev#2868). Goose
sees version 1 applied on a database created by 1.0 and runs nothing, so
the controller finds no runtime_revision.credentials, no agent instance
operation_id and executor_id, no generated pinned_checkpoint_id and no
DELETED state, and fails to store a runtime revision with
column "credentials" of relation "runtime_revision" does not exist.

000002 tells the two baselines apart by the four columns the current one
added: none of them present is the 1.0 baseline, which it upgrades with
the current baseline's columns, constraints (under the names a fresh
install gives them) and partial index; all of them present is a database
the current 000001 created, which it leaves unchanged; anything else is
neither baseline and fails the migration, in its transaction.

agent_instance_checkpoint.source_name stays: the 1.0 controller reads and
writes it in every checkpoint query and the current controller never
names it, so a migrated database still runs 1.0 and nothing is lost. The
Down section has nothing to undo for the same reason.

TestCoreUpgradesThe1_0Baseline replays the 1.0 baseline (a copy of it in
testdata/core-1.0) with rows, runs the builtin migrations over it and
compares the schema with a fresh install's, which 000002 must leave as
000001 made it; TestCoreRefusesAMixedBaseline proves the refusal.
TestBuiltinMigrationsRoundTrip expects every migration a source ships.

Kagent 1.0 recorded core version 1 with an earlier 000001 baseline, and
000001 has since changed in place (upstream kagent-dev#2847, kagent-dev#2857, kagent-dev#2868). Goose
sees version 1 applied on a database created by 1.0 and runs nothing, so
the controller finds no runtime_revision.credentials, no agent instance
operation_id and executor_id, no generated pinned_checkpoint_id and no
DELETED state, and fails to store a runtime revision with
column "credentials" of relation "runtime_revision" does not exist.

000002 tells the two baselines apart by the four columns the current one
added: none of them present is the 1.0 baseline, which it upgrades with
the current baseline's columns, constraints (under the names a fresh
install gives them) and partial index; all of them present is a database
the current 000001 created, which it leaves unchanged; anything else is
neither baseline and fails the migration, in its transaction.

agent_instance_checkpoint.source_name stays: the 1.0 controller reads and
writes it in every checkpoint query and the current controller never
names it, so a migrated database still runs 1.0 and nothing is lost. The
Down section has nothing to undo for the same reason.

TestCoreUpgradesThe1_0Baseline replays the 1.0 baseline (a copy of it in
testdata/core-1.0) with rows, runs the builtin migrations over it and
compares the schema with a fresh install's, which 000002 must leave as
000001 made it; TestCoreRefusesAMixedBaseline proves the refusal.
TestBuiltinMigrationsRoundTrip expects every migration a source ships.

…rk (kagent-dev#2847)

Signed-off-by: alexdarbyshire <[email protected]>

---
*🤖 written by Claude (start)*

"Checkpoint" is "Snapshot" in the chat. A snapshot carries a name, its
mark on the transcript carries Fork, Rename and Delete, and pressing the
mark opens the record behind it.

| Change | Detail |
|---|---|
| A snapshot has a name | `Checkpoint.name`, generated on creation as
`<agentInstanceId>-<headTaskId>`. |
| Renaming one | `UpdateCheckpointName`, mirroring
`UpdateAgentInstanceName`. An empty name restores the generated default,
so a fork always has something to be called. |
| A fork takes the snapshot's name | The chat no longer renames after
forking, because `ForkAgentInstance` copies the checkpoint's name onto
the new conversation. |
| The mark carries its actions | Fork, Rename and Delete sit under it;
pressing the mark itself opens the record, which holds the id, turn,
state and age. |
| Two extension points | `app_agents_agentChat_snapshotDivider_actions`
beside those controls, and `app_agents_agentChat_snapshotDetails_footer`
at the foot of the record. Both take `{ snapshotId, instanceId, label
}`. |

The name lives in the `data` payload with the rest of the checkpoint,
and the `source_name` column is gone. Nothing filters or sorts
checkpoints by name, so a column earned it nothing and cost a second
place for the value to live.

## Testing

1. Chat with an agent for two turns, then take a snapshot from the
composer.
2. The mark reads `Snapshot "<instance id>-<turn id>"`, clipped if it is
long. Hovering offers to open the record; the full name is on the record
itself.
3. Send a third turn and take a second snapshot.
4. Rename the first one from its mark, reload the page, and press the
mark. The new name is on the record.
5. Fork from that mark. The new conversation opens named after the
snapshot, holding only the turns above it.
6. Check both themes: the mark is a tinted card, and Rename's outline
stays legible on each.

---
*🤖 written by Claude (end)*

---------

Signed-off-by: Nicholas Bucher <[email protected]>