Add native Telegram recovery command alias for remote clisbot restart

[leolionart]

Problem

I need a reliable way to remotely recover clisbot when it stops being operational.

The current failure mode is not just that an agent session is busy. Sometimes clisbot can become unusable from the remote operator's point of view because of issues such as:

• a stuck or stale tmux runner session
• stale runtime/session state that prevents new work from being admitted
• a runner that appears active even though it is no longer making progress
• Telegram still being the only available remote surface, but clisbot no longer responding normally
• any other runtime state where clisbot effectively cannot accept or process new commands

In those situations, the operator needs a way to actually restart or recover clisbot remotely, not just send another normal agent prompt.

Requested capability

Please provide a first-class remote recovery mechanism for clisbot.

The goal is: when clisbot is stuck, unhealthy, or no longer responding correctly, an authorized operator should still have a supported way to trigger a real recovery flow that can bring clisbot back to a working state.

This recovery flow should be able to handle problems like stuck tmux sessions, stale session state, broken runner state, or other conditions that prevent clisbot from receiving or processing normal commands.

Expected behavior

A good solution would:

1. Be designed specifically for remote recovery, not ordinary chat handling.
2. Work even when the normal agent/runner path is stuck.
3. Be protected by the existing owner/admin permission model or a stricter recovery permission.
4. Perform the necessary restart/recovery steps to make clisbot usable again.
5. Return a compact result summary when possible.
6. Avoid unsafe broad process killing unless explicitly designed and documented.

Why this matters

clisbot is useful precisely because it allows remote operation through chat surfaces. When clisbot itself becomes stuck, the operator may not have immediate access to the machine. A reliable remote recovery path is therefore an important operational feature, not just a convenience command.

The key requirement is not a specific command syntax. The key requirement is a supported way to recover clisbot remotely when it is stuck badly enough that normal interaction no longer works.

[leolionart]

Additional confirmed failure mode on 0.1.54-beta.3

I encountered this issue again on macOS (Mac-mini.local) with the Codex runner. This provides a concrete example of the stale runtime/session state described above.

Visible symptom

clisbot repeatedly displayed:

Runner session was lost. Attempting recovery 5/2 by reopening the same conversation context.

The 5/2 value is notable: the recovery attempt counter continued beyond the configured maximum of 2 attempts.

Observed state

For the affected Telegram DM session:

• clisbot status reported the service and Telegram connection as active.
• The tmux runner pane still existed and was alive.
• The Codex runner had already returned to its normal CLI prompt.
• clisbot queues status reported items: 0.
• clisbot status reported Active runs: none.
• The persisted entry in state/sessions.json still contained runtime.state: running.
• Because the tmux target still existed, the normal reconciliation path did not reset the persisted runtime to idle.
• New work could therefore be blocked or routed into repeated recovery even though no run was actually active.

Recovery that worked

The affected session was recovered without killing the tmux runner:

1. Back up state/sessions.json.
2. Change only the affected session entry from runtime.state: running to idle.
3. Leave the persisted Codex session ID intact.

After this repair:

• runner list showed the session as idle.
• Queue remained empty.
• Telegram direct-send succeeded.
• The other independent clisbot home was unaffected.

Suspected areas

Two related behaviors may need investigation:

1. Mid-run recovery attempts are apparently not globally capped. After a successful reopen followed by another loss, the carried recoveryAttempt can continue increasing, producing values such as 5/2.
2. When a recovered runner returns to the CLI prompt without an active run, the persisted runtime state is not always finalized from running to idle while the tmux session remains alive.

Suggested expected behavior

• Never report or execute a recovery attempt greater than MID_RUN_RECOVERY_MAX_ATTEMPTS for one interrupted run.
• If the queue is empty, there is no in-memory active run, and the runner is back at a ready CLI prompt, reconcile persisted runtime.state to idle even when the tmux session still exists.
• Consider exposing this inconsistency in clisbot status or providing a supported state-reconciliation command.