Controller-mode sessions adopt stopped bots because performance snapshots are treated as live membership

[mlguys]

Describe the bug

Controller-mode Agent sessions can adopt a stopped bot and display it as RUNNING because Condor treats the latest controller-performance snapshot as proof of live bot membership.

TickEngine._adopt_running_bots() obtains candidates through fetch_all_bot_performance(), which is backed by get_latest_controller_performance(). Controller performance is useful for PnL and history, but its latest record can remain available after a bot is no longer active. The session performance rollup and dashboard also use this data to populate bot_names and infer the RUNNING badge.

This can disagree with Hummingbot API's active-bot registry. In the observed case, get_latest_controller_performance() still contained a timestamped bot instance while get_active_bots_status() returned no bot in that namespace. A newly started Agent session consequently recorded the old bot as origin: adopted, attributed it to the new session, and displayed the old deployment as running.

This is a core controller-mode lifecycle issue rather than a strategy-specific problem. For example, any market-making Agent using a stable bot namespace can inherit a stopped deployment when a new Agent session begins.

Expected behavior

• Only bots present in the authoritative active-bot registry are eligible for cross-session adoption.
• Controller-performance snapshots provide metrics and historical attribution, but never establish live membership.
• The session dashboard marks a deployment RUNNING only when its exact timestamped bot instance is in the active-bot registry.
• Historical controller rows remain visible and are marked STOPPED when the deployment is not active.

Actual behavior

• A stopped timestamped bot can be adopted by a new session.
• The stopped deployment can appear under the new session with a RUNNING badge.
• Injected ownership/accounting can conflict with fresh lifecycle reconciliation from get_active_bots_status().

Impact

• Incorrect slot and capital occupancy.
• New deployments may be unnecessarily suppressed.
• Agents may spend ticks reconciling a ghost bot or attempt operations against a stopped instance.
• Session attribution and dashboard lifecycle state become misleading.

Steps to reproduce

1. Run a controller-mode Agent that uses a stable namespaced bot name and deploy a timestamped bot instance.
2. Stop/archive the bot while its latest controller-performance record remains available.
3. Start a new Agent session for the same Agent and strategy namespace.
4. Let the first-tick adoption pass run.
5. Compare the new session's owned_bots.json and dashboard with get_active_bots_status().
6. Observe that the stopped instance may be recorded as adopted and shown as RUNNING even though it is absent from the active-bot registry.

Suggested fix

• Make get_active_bots_status() (or an equivalent authoritative active-container registry) the sole source for live membership in _adopt_running_bots().
• Keep get_latest_controller_performance() exclusively for PnL, controller details, and historical deploy records.
• Pass authoritative active instance names separately into the Agent performance/session-report layer so bot_names and dashboard badges do not infer lifecycle from performance presence.
• Use the exact timestamped bot name plus controller ID as the compound identity when correlating controller records.
• Treat an unavailable active-status request as unknown and retry adoption; do not interpret request failure as an empty namespace.

Suggested regression coverage

• A stopped bot with a retained performance snapshot is not adopted.
• A genuinely active timestamped bot is adopted across sessions.
• A stopped deployment remains in historical controller rows but is labeled STOPPED.
• An active-status request failure defers adoption rather than adopting from performance or declaring the namespace empty.

Attach required files

No Gateway configuration or logs are involved. The mismatch is between Condor's controller-performance-based adoption/reporting and Hummingbot API active-bot membership.