feat: make Telegram slash-command sync always-on

[pinion05]

Summary

Remove the startup gate and always attempt Telegram slash-command synchronization during bot startup.

Why

The bot already has a single shared command registry and a non-fatal sync path. Making sync opt-in creates drift between product expectation and actual behavior: command suggestions may stay stale unless the operator remembers to enable a flag.

Proposal

• remove from runtime config
• stop parsing or documenting
• always call during startup
• keep sync non-blocking and warning-only on failure
• update focused tests and README to match the always-on contract

Acceptance Criteria

• startup always attempts Telegram command sync
• startup still continues when sync fails or hangs
• README no longer documents an opt-in env var for command sync
• config tests and startup tests reflect the new default behavior

[pinion05]

Investigation summary from March 12, 2026.

Reported symptom:

• Running commit 5599e02 (fix: address telegram sync review feedback) left Telegram in typing... for roughly 3 hours.
• Downgrading to a09a55c (Merge pull request #33 from pinion05/fix-issue-32-telegram-routing) produced an immediate reply.

What the diff review showed:

• 5599e02 itself does not change runtime behavior in src/; it updates tests/docs.
• The runtime behavior change relevant to Telegram command sync was introduced earlier in 49dd36a.
• That earlier change made startup command sync unconditional and removed the TELEGRAM_SYNC_COMMANDS startup gate.

What the follow-up test showed:

• On March 12, 2026, a same-code-path A/B test with command sync explicitly ON vs OFF both replied normally.
• That weakens the hypothesis that startup slash-command sync is the sole/direct cause of the long typing... incident.

Current most plausible bottlenecks:

1. runTurn / Codex-side request occasionally hanging or taking extremely long.
2. Typing heartbeat shutdown or final reply path occasionally stalling.
3. Operational instability such as duplicate bot instances or polling conflicts.

Observed during investigation:

• A local bot log contained 409 Conflict: terminated by other getUpdates request, which suggests at least one overlapping polling instance existed at some point.
• Current local cron job definitions were all disabled, so cron overlap does not look like the active reproducer right now.

To improve observability, a local diagnostic patch was added in the feature worktree:

• restored TELEGRAM_SYNC_COMMANDS as default ON + explicit OFF for A/B startup testing
• added startup sync timing logs
• added runtime trace hooks for:
  • input.received
  • typing.start / typing.started / typing.stopped
  • bot-level run.start / run.done / run.failed
  • runtime-level codex.start / codex.done / codex.failed
  • reply.start / reply.done
• added targeted tests covering trace helper, bot trace flow, and runtime trace flow

Current conclusion:

• Do not pin the incident on 5599e02 alone.
• If this feature line introduced a regression, the first runtime entry point is 49dd36a, not 5599e02.
• However, the March 12 A/B result makes always-on slash-command sync a weaker root-cause candidate than runTurn, typing cleanup, or process-level overlap.

Suggested next step:

• reproduce once more with runtime tracing enabled and inspect the exact last successful event before the stall.