feat: support viewing, switching, and rolling back artifact revisions in Dashboard

Feature description

Extend the Dashboard so users can inspect and switch between immutable artifact revisions, and roll an artifact back to a selected historical revision.

The feature should cover Memory, Profile, Topic Memory, Experience, Skill, Prompt, and Handoff where the underlying artifact family supports revisions.

Problem and proposed solution

The current Dashboard generally shows the current head revision. Some pages can open an exact revision when its artifact ID and revision are already known, but there is no consistent history browser, revision selector, or rollback workflow across artifact families.

Add a unified revision experience:

1. Show a history entry point for each artifact, with revision number, creation time, author or actor when available, lifecycle state, and source or lineage references.
2. Allow users to open an exact historical revision and compare it with the current revision or another selected revision.
3. Allow authorized users to select a historical revision and choose Roll back.
4. Implement rollback as a new revision whose content is copied from the selected historical revision. Do not delete, rewrite, or hide existing revisions.
5. Require an explicit confirmation and reason for rollback, enforce optimistic concurrency against the current head, and record an audit event containing the actor, source revision, new revision, reason, and timestamp.
6. Make the resulting revision visible in the normal current-head view and in the history list.

The UI should clearly distinguish the current revision, historical revisions, and the new revision created by a rollback. Rollback must preserve source references and artifact lineage according to each family’s rules.

Alternatives considered

• Showing only a manually entered artifact_id and revision is useful for debugging but does not provide discoverability or a safe rollback workflow.
• Replacing the current row in place would lose auditability and conflict with immutable artifact revision semantics.
• Direct database edits would bypass authorization, concurrency checks, lineage, and audit records.

Acceptance criteria

• A user can browse revision history from the Dashboard for every supported artifact family.
• A user can view the exact content and evidence of a selected historical revision.
• A user can compare two revisions with a readable diff where the content model supports comparison.
• An authorized user can roll back to a selected revision after entering a reason and confirming the operation.
• Rollback creates a new immutable revision and leaves all previous revisions readable.
• Stale-head or concurrent updates are rejected safely and explained in the UI.
• The operation is covered by API, Dashboard, authorization, audit, and regression tests.

Additional context

The current API already exposes exact artifact revision reads and revision listing for several families. The Dashboard should build on those APIs instead of introducing a separate mutable history store.

Are you willing to contribute?

• Yes, I am willing to contribute code, docs, or design feedback.