docs: Campaign CT gate PASSED; file #441 (death/lifestone return, intermittent); retire the CT-era hover probe

The ACDREAM_PROBE_UI_HOVER probe dies with its closed investigation
(scrollbar hover, fixed 2d6333f8) per the launch-options rule; #441
stays filed with its probe recipe for the next occurrence.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/ISSUES.md

@@ -24,6 +24,41 @@ What does NOT go here:
 - Every session: scan OPEN issues at start; promote/close anything we touched during the session before ending.
 - Promoting to a Phase: mark as `DONE (promoted to Phase X)` + commit SHA where the Phase entry landed.
 
+## #441 — Death return to lifestone: stuck in portal once; arrived once with world not ready (missing doors/portals)
+
+**Status:** OPEN (intermittent — did not reproduce under probes 2026-08-24).
+**Component:** reveal generation / death teleport / entity hydration
+
+Owner observed twice (before probes were armed), then could NOT reproduce in a
+probed session the same day:
+
+1. **Run 1:** died, and the death teleport left the client **stuck in portal
+   space** (the authored tunnel never released).
+2. **Run 2:** arrived at the lifestone while the world was **not ready** —
+   "missing doors, portals and stuff". Note: doors and portal objects are
+   server-spawned WEENIES, not dat-baked statics
+   (`claude-memory/feedback_weenie_vs_static.md`) — so this symptom may be
+   **entity hydration lagging the viewport reveal** (CreateObject stream not
+   yet drained when the reveal completed), not a composites/terrain gap.
+   Possibly related to #433 (stale entities near Holtburg after /ls-style
+   teleports — the flush direction of the same coin).
+
+**Owner's repro protocol (worked twice pre-probe, then went cold):** log in,
+position far from the lifestone, log off, log on again, get killed. The
+fresh-login-then-die sequence appears to matter.
+
+**Probe recipe (armed and documented, ready for the next occurrence):** launch
+with `ACDREAM_PROBE_REVEAL=1` + `ACDREAM_PROBE_REVEAL_TIMING=1` and keep the
+log. The always-on `[world-reveal]` lines plus `[reveal-timing]` per-edge
+attribution distinguish the two shapes directly: symptom 1 = a readiness edge
+that never arrives for the death generation; symptom 2 = `complete` firing
+with the object stream still behind.
+
+**Healthy baseline (2026-08-24, `launch-death-repro-3.log`):** login gen and
+two portal gens all converge; readiness edges complete in 83-1400 ms;
+`totalMs` ≈ 5.5-5.7 s of which the balance after `materialized` is the
+authored portal-tunnel presentation, not a stall.
+
 ## #440 — CLOSED: Trained skill did not move to its section (and raise buttons never visually un-ghosted) until the next click
 
 **Status:** CLOSED 2026-08-24, found by the owner during the CA5 drive.