Trace recording / time-travel debugging

## Description

Ghidra's trace model supports multiple snapshots, enabling time-travel debugging where users can scrub back through execution history. Currently the plugin overwrites the same snapshot on each stop.

## Proposed implementation

- Create a new snapshot on each stop event instead of overwriting (already using `trace.snapshot()`)
- Retain register and memory state per snapshot
- Let Ghidra's built-in timeline UI navigate between snapshots
- Add configurable limits (max snapshots, memory per snapshot) to avoid unbounded growth
- Optionally record memory diffs instead of full 64KB per snapshot

## Why this matters

Time-travel debugging is extremely powerful for understanding 6502 code behavior, especially for timing-sensitive code (raster effects, SID music, etc.) where you need to understand what happened N instructions ago.

Bei diesem Issue geht es darum, die Snapshot-Behandlung des Plugins im Trace-Modell zu ändern. Suche nach dem Handler für das Stop-Ereignis, in dem `trace.snapshot()` aufgerufen wird. Verstehe, wie der Register- und Speicherzustand derzeit erfasst und gespeichert wird. Überprüfe die Integration von Ghidras Timeline-UI und implementiere konfigurierbare Grenzen für die Aufbewahrung von Snapshots. Zum Testen muss das Plugin mit einem 6502-Ziel ausgeführt werden, um zu überprüfen, dass die Zeitreise-Navigation funktioniert.

Vom Indexierungsmodell aus dem Issue-Text verfasst.