Deliver the Telegram live task console and mobile control UX

Parent: #6

Depends on the shared dispatcher, live output, and worker supervisor issues listed in #6.

## Target experience

A phone user can open the current task, inspect recent Codex output like a controlled read-only terminal view, refresh or page backward, and stop or answer an interaction without typing long commands.

## Scope

- add Current Task and Live Output entry points to status/task views;
- add inline buttons for Refresh, More, Latest, Back, Stop Current, and Stop After Current;
- show task status, elapsed time, last output age, attempts, workdir label, and pending interaction;
- keep Telegram messages within API limits and preserve stable button dimensions/labels;
- edit an existing live-output message when practical, with send-new fallback;
- keep `/status`, `/tasks`, `/tail`, text commands, and voice commands as accessible alternatives;
- handle expired callbacks and missing/deleted tasks clearly.

## Acceptance criteria

- [ ] A running task can be reached from the first task/status screen in at most two taps.
- [ ] Refresh shows new output without repeating the whole history.
- [ ] More pages older output using a stable cursor.
- [ ] The user can distinguish idle, running, waiting for interaction, waiting for limit, stopped, failed, and completed states.
- [ ] Buttons remain authorized to the configured chat and callbacks are idempotent.
- [ ] Mobile-friendly rendering is tested against long titles, paths, output, and errors.
- [ ] English user guide and command/button reference are updated.

## Non-goal

This is a supervised, structured console, not an unrestricted tmux or SSH terminal.

## Future client compatibility

This issue does not add an HTTP server, but its presentation boundary must remain reusable by issue #41:

- Telegram views consume transport-neutral application view models rather than SQLite rows or Bot API-shaped service responses;
- task, run, worker, interaction, and live-output actions use query/command services with structured errors;
- output cursors, callback idempotency, authorization, and stale-state behavior can be exposed later through authenticated HTTP/SSE without changing their meaning;
- Telegram rendering and button payloads remain adapter concerns.

Additional acceptance criterion:

- [ ] The live console view models and actions contain no Telegram, SQLite, process-id, or coding-agent SDK types.

Begin with parent issue #6 and the existing status/task views, then trace the shared dispatcher, live output, and worker supervisor dependencies. Compare the existing /status, /tasks, /tail, text, and voice command paths with the requested Telegram views and actions. Done means the mobile console meets the acceptance criteria, updates the user guide and command/button reference, and keeps its view models and actions free of Telegram, SQLite, process-ID, and coding-agent SDK types.

Written by the indexing model from the issue text.