"Run & Track Memory (Current File)" dead-ends: toast says "take a snapshot", but stopping produces no chart/trace/report

[MelbourneDeveloper]

Summary

Python Processes → "Run & Track Memory (Current File)" on a .py file
(examples/debug_demo.py) produces nothing usable:

• It launches a debug session and shows a toast: "Basilisk: Memory tracking
  started. Take a snapshot to inspect allocations."
• The program runs to completion (Debug Console shows full output through
  Sum: 88).
• Stopping the process just terminates the debugger. No memory chart, no
  dashboard, no trace, no summary — nothing.

The "Run & Track Memory" feature, as experienced, can never yield a result in
this flow.

Steps to reproduce

1. Open examples/debug_demo.py.
2. Click Run & Track Memory (Current File) in the Python Processes panel.
3. Observe the "Memory tracking started. Take a snapshot…" toast; the program
   runs to completion.
4. Stop the process.

Expected: an end-of-run memory report — a chart / dashboard / allocation
trace — or at minimum clear, actionable guidance on how to capture one.

Actual: a toast, then on stop the debugger terminates and nothing is shown.

Root cause — the flow structurally dead-ends

The memory model requires the debuggee to be paused at a breakpoint to
capture anything, and produces a result only via a manual snapshot — neither
of which this entry point arranges or communicates:

1. The "take a snapshot" instruction omits the hard precondition. A snapshot
   round-trips through the paused debuggee and bails unless a frame is stopped:

   • memory-profiler.ts:251 — the
     toast says only "Take a snapshot to inspect allocations."
   • memory-profiler.ts:183-189
     — runMemoryScript() returns early with "Pause the debugger at a
     breakpoint to inspect memory" when nothing is stopped.

   If the program runs to completion (as here — there is no breakpoint set), there
   is never a stopped frame, so a snapshot is impossible. The toast leads the user
   to a dead end.

2. Stop produces no report whatsoever. handleMemoryStop() only tears down
   state; it emits no summary, chart, dashboard, or trace:

   • memory-profiler.ts:356-362
     — clears activeMemorySessionId, decorations, and status bar. That's all.

3. Debug-session termination is not finalised into a result. When the user
   stops the process, the terminate listener only refreshes the status bar — it
   never produces an end-of-session memory report:

   • memory-profiler.ts:116 —
     onDidTerminateDebugSession(() => refreshMemoryStatusBar()).

A memory dashboard (openMemoryDashboard) / .heapprofile only ever appears
from handleMemorySnapshot()
(memory-profiler.ts:259-276),
which the user is never guided to reach and which is unreachable once the program
has finished.

Required fix

• "Run & Track Memory (Current File)" must end in a visible result: either
  auto-pause at a sensible point and capture a baseline/final snapshot, or, on
  session end, finalise the memory session into a dashboard/trace.
• If a pause-at-breakpoint is genuinely required, the entry point must say so
  up front (and ideally stop the debuggee for the user) — not after the program
  has already exited.
• handleMemoryStop() / onDidTerminateDebugSession should surface whatever was
  captured (or an explicit "nothing was captured because …") rather than silently
  clearing state.

Notes

• Entry point is ahead of main. The running build shows three buttons
  ("Run & Profile CPU (Current File)", "Run & Track Memory (Current File)",
  "Refresh") and the copy "No Python processes running. The list refreshes
  automatically." — none of which exist in the current tree's
  viewsWelcome (package.json:79-88,
  which has two buttons and different copy). The basilisk.memoryTrackProcess
  command title is "Track Memory"
  (package.json:318-324). Reconcile the
  current-file memory entry point so the reproduction maps to committed code.
• Sibling of "Run & Profile Current File" launches a debug session, then the resulting .cpuprofile fails to open #145 (the CPU "Run & Profile Current File" flow), which has the same
  "enters debugging mode" UX concern and a broken result view.
• Profiling/memory UI is currently behind the dev/test gate ([PROFILE-UI-GATE]),
  so this is not shipped-user-facing yet — but the end-to-end flow must work
  before the gate opens.

Spec / cross-references

• [LSPPROF], [PROFILE-UI-GATE] — docs/specs/LSP-PROFILING-SPEC.md.

Acceptance criteria

• "Run & Track Memory (Current File)" ends in a visible memory result
  (dashboard / chart / trace), or gives explicit, up-front guidance on how to
  capture one before the program exits.
• Stopping the session never silently produces nothing — either a report or
  an explicit reason no data was captured.
• The current-file memory entry point maps to committed code, and an e2e test
  covers the run→track→result flow cross-referencing the spec ID.