Burst detector #290 size cap reclassifies TRN LTS rebound as tonic (UI never shows it as a burst)

[JCorson]

Summary

The default-fixed burst detector's tight-cluster size cap structurally cannot represent the TRN low-threshold-spike (LTS) rebound burst. analyze_bursts_from_result (the path the Reflex UI takes for HYPERPOLARIZATION_STEPS / step-release protocols on the TRN preset) reclassifies the entire rebound as sustained tonic firing and surfaces only the short cold-start cluster. A user running the rebound protocol on TRN therefore never sees the rebound reported as a burst.

Where

patch_sim/analysis/burst_metrics.py:

• _TIGHT_CLUSTER_MAX_ISIS: int = 7 (line 108) → effective survivor cap is spike_count <= _TIGHT_CLUSTER_MAX_ISIS + 1 = 8 spikes (lines ~456–468, the method == "default-fixed" branch).
• Bursts with more than 8 spikes are removed from bursts and their spikes folded into unburst_spike_count. The comment there documents this as intentional (issue Burst analyzer reports 1 fake burst for tonic firing under default threshold #290): "Real LTS-style bursts top out at 7–8 spikes ... anything longer with all-short ISIs is tonic."

Why it's wrong for TRN

Empirically, on NEURON_PRESETS[TRN] with a -4 µA/cm² × 500 ms hyperpolarizing step (pre 200 ms, post 200 ms):

• The post-release LTS rebound is a clean, unambiguous high-frequency burst: ~16 Na⁺ spikes between ~731–781 ms at ~230–563 Hz (textbook Huguenard & Prince 1992 phenotype, pushed to the high end by the depolarized h-gate shift introduced in TRN: deep kinetic retune to remove cold-start depol-block on rising LTS edge #348 / PR TRN deep retune: h-gate shift fix for cold-start depol-block (closes #348) #367).
• analyze_bursts_from_result(...) returns burst_count = 1 with the only burst being the 5-spike cold-start cluster at t≈28 ms (n=5, f=250). The 16-spike rebound is silently reclassified as tonic.

So the #290 cap (sized for ~3–8 spike TC/STN LTS bursts) is below the TRN rebound size, especially after the #348 h-gate retune. The cap is correct for its original purpose (preventing sustained tonic trains from being fabricated into one giant burst) but has no per-preset awareness that a 16-spike tight cluster is the biologically expected TRN rebound.

How it surfaced

During follow-up on the PR #367 code review. The PR's burst tests had been loosened to "match any detected burst with 5–15 spikes @ 200–600 Hz", which passed only because the cold-start cluster coincidentally matches that phenotype — masking the fact that the rebound is never surfaced. Those tests have since been rewritten to pin the rebound directly from the post-release spike train (tests/_rebound.py::post_release_rebound), with the detector call kept only as a pipeline smoke check. So the test suite is now honest about this, but the underlying UI/analysis behavior is unchanged: the TRN rebound is not reported as a burst in the UI.

Possible directions (not yet decided)

• A per-preset / per-call escape hatch so LTS-rebound contexts bypass or raise the size cap (TRN rebounds legitimately run to ~16+ spikes; deeper hyperpolarizations to ~25+).
• Distinguish "tight cluster followed by return to rest/tonic baseline" (a real terminating LTS burst) from "sustained tight train to end of trace" (true tonic) instead of using a fixed spike-count cap.
• Document the cap as a known limitation of analyze_bursts_from_result for large LTS rebounds and surface rebound metrics through a different code path for affected presets.

Acceptance

• Running HYPERPOLARIZATION_STEPS (or a -4 µA × 500 ms step-release) on the TRN preset reports the post-release LTS rebound as a burst with ~5–35 spikes @ 200–600 Hz.
• The Burst analyzer reports 1 fake burst for tonic firing under default threshold #290 protection against tonic trains being fabricated into bursts is preserved for tonic-firing presets (Purkinje / HH tonic regression tests still pass).