fix: a re-plan drops the holes it invalidated and restarts the tick they are addressed by

rebuild_locked() replaced the store, so produced() restarted at 0 while the
producer's tick_ kept counting: a hole's slot and tick addressing then described
a buffer that was gone, forget_holes_before() could not retire it, and a
backfill's amend fell outside the ring -- repairing nothing while the hole was
still marked repaired, which is the band reporting the opposite of the truth. A
re-plan generation is the signal rather than the stride/channel-count guard,
which a reconnect with an identical CONFIG leaves unchanged. slot_base_ is left
alone: it is relative mode's clock origin and must not walk backwards when the
user retypes the window.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

src/model.hpp

@@ -551,6 +551,13 @@ class ScopeModel {
   /// Rebuilds buffers from the current channel list. Caller holds `mutex()`.
   void rebuild_locked();
 
+  /// Counts buffer re-plans: every `rebuild_locked()` bumps it. The producer caches the value
+  /// it last saw and resets the state tied to the old store when it moves (see
+  /// `Acquisition::on_data`). Not an atomic on purpose: `rebuild_locked()` only runs under
+  /// `mutex()` and the producer holds that lock for all of `on_data`, so a plain read under the
+  /// lock is correct, and a reconnect with an identical CONFIG is a re-plan this sees and the
+  /// stride/channel-count comparison does not.
+  unsigned plan_generation() const noexcept { return plan_generation_; }
 
  private:
   void rebuild_channels();
@@ -614,6 +621,8 @@ class ScopeModel {
   Partition part_;
   std::unique_ptr<BufferStore> store_;
   std::vector<Hole> holes_;
+  /// See `plan_generation()`. Written and read under `mutex()` only.
+  unsigned plan_generation_ = 0;
   TriggerConfig trigger_{};
   StreamStats stats_{};
   f64 epoch_ = 0.0;