chore: document regenerate lifecycle-rollback limitation with warning log (T83.4)

When a regenerate replaces an assistant_turn that already produced
lifecycle transitions (``event_started`` / ``event_completed`` /
``event_cancelled``), those transitions are NOT rolled back before
``detect_event_transitions`` re-runs against the new text. A
regenerate-after-completion can therefore double-emit promotion
artifacts.

Phase 3.5 first cut (per the task plan): documentation + WARNING log
naming the affected event_log ids. The actual undo pass is invasive
(re-projection / inverse-handler dispatch) and is deferred to Phase 4.

Implementation:
- TODO docstring block at the top of ``regenerate_assistant_turn``.
- Module-level ``_log = logging.getLogger(__name__)``.
- Scan immediately after the original assistant_turn row is located:
  joins event_log lifecycle rows to the events table on event_id so we
  can scope by chat (lifecycle payloads carry only ``event_id``, not
  ``chat_id``). Filter ``id > original_assistant_event_id`` as the
  positional linkage to "transitions emitted as part of (or after)
  this turn's processing."

Decision (asked in the brief): the scan uses the ``id > original``
heuristic rather than scanning for explicit references. Lifecycle
event payloads do not carry a back-pointer to the assistant_turn that
triggered them — the linkage is positional in the event log. A tighter
linkage would require either adding a payload field on lifecycle
events (cross-cutting schema change) or threading the just-appended
assistant_turn id into ``detect_event_transitions``'s emit calls
(narrow but still cross-cutting). The positional heuristic is loose
but conservative: a turn that emits no lifecycle events produces no
warning, and the warning's purpose is operator-visible breadcrumbs
not an exact rollback set.

Test: test_regenerate_with_prior_lifecycle_logs_warning seeds a turn
that produced ``event_started`` + ``event_completed`` rows and asserts
the WARNING fires with the expected ids.

chat/services/regenerate.py

@@ -70,6 +70,7 @@ from __future__ import annotations
 
 import asyncio
 import json
+import logging
 from sqlite3 import Connection
 
 from chat.config import Settings
@@ -91,6 +92,8 @@ from chat.state.world import active_scene, get_chat
 from chat.web.pubsub import publish
 from chat.web.render import render_turn_html
 
+_log = logging.getLogger(__name__)
+
 
 async def regenerate_assistant_turn(
     conn: Connection,
@@ -109,6 +112,19 @@ async def regenerate_assistant_turn(
 
     Raises :class:`ValueError` when the chat or the assistant_turn event
     cannot be found — the FastAPI route translates this to 404.
+
+    .. note::
+       **Lifecycle-rollback limitation (T83.4, Phase 4 follow-up).**
+       When the superseded turn already produced lifecycle transitions
+       (``event_started`` / ``event_completed`` / ``event_cancelled``),
+       this function does NOT roll those rows back before re-running
+       ``detect_event_transitions`` against the regenerated text. A
+       regenerate-after-completion can therefore double-emit promotion
+       artifacts if the new text re-completes the same event. Phase 3.5
+       only documents the gap and emits a WARNING log naming the
+       affected event_log ids; the actual undo pass is invasive
+       (re-projection / inverse-handler dispatch) and is deferred to
+       Phase 4. See the ``# T83.4`` block below for the warning emit.
     """
     chat = get_chat(conn, chat_id)
     if chat is None:
@@ -141,6 +157,40 @@ async def regenerate_assistant_turn(
     original_assistant_payload = json.loads(row[0])
     original_user_turn_id = original_assistant_payload.get("user_turn_id")
 
+    # T83.4: scan for downstream lifecycle transitions emitted by the
+    # superseded turn — they're not being rolled back (see method
+    # docstring). Heuristic: any ``event_started`` / ``event_completed``
+    # / ``event_cancelled`` event_log row with id strictly greater than
+    # the original assistant_turn's id was emitted as part of (or after)
+    # that turn's processing. Lifecycle events don't carry ``chat_id``
+    # in their payload (their payload references an ``event_id`` FK to
+    # the ``events`` table, which holds chat_id), so we join through
+    # ``events`` to scope to this chat.
+    #
+    # A WARNING log surfaces the affected event ids so operators can
+    # spot double-emit cases until the Phase 4 rollback pass lands.
+    unrolled_lifecycle = conn.execute(
+        "SELECT el.id, el.kind FROM event_log AS el "
+        "JOIN events AS ev "
+        "  ON ev.event_id = json_extract(el.payload_json, '$.event_id') "
+        "WHERE el.kind IN ("
+        "    'event_started', 'event_completed', 'event_cancelled'"
+        "  ) "
+        "  AND ev.chat_id = ? "
+        "  AND el.id > ? "
+        "ORDER BY el.id ASC",
+        (chat_id, original_assistant_event_id),
+    ).fetchall()
+    if unrolled_lifecycle:
+        _log.warning(
+            "regenerate_assistant_turn: %d lifecycle transition(s) from "
+            "superseded turn %s are NOT being rolled back (Phase 4 "
+            "follow-up). Affected event ids: %s",
+            len(unrolled_lifecycle),
+            original_assistant_event_id,
+            [r[0] for r in unrolled_lifecycle],
+        )
+
     # 1a. Look up any sibling interjection beat in the same turn group
     # (T73.2). The original group is (primary + optional interjection),
     # both pinned to the same ``user_turn_id``. The interjection has a