v3.0.0

Approval on your phone, on every platform — and the version numbers across the CLI, the Mac app and the VS Code extension now line up.

About the version

Codeep V3 is one release across three surfaces, so the three carry one number.
The CLI moves 2.25.0 → 3.0.0, the VS Code extension 2.9.0 → 3.0.0, and the Mac
app 1.14.0 → 3.0.0. Nothing here is a breaking change — the major is the
alignment, said out loud rather than left to look like an accident. The GitHub
Action keeps its own v1.x line: it is a separate product with its own
consumers and its own supply-chain pinning.

Added

• Answer a confirmation from your phone, over Telegram. When a run stops on
  a dangerous tool it waits — and if you have walked away, it waits for as long
  as you are gone. Connect a bot with /telegram and the same question arrives
  on your phone with the same three answers. Whichever you use first decides;
  answering in the terminal takes the message down rather than leaving buttons
  that no longer do anything, and answering on the phone closes the terminal
  dialog without running either of its callbacks.

  This is where Telegram earns its keep. The Mac app can carry approvals through
  the user's own iCloud; Linux and Windows have nothing of the sort. The bot API
  is polled outbound, so there is no server to host and no inbound port to open,
  and the same code works everywhere the CLI does.

  Only the chat ID you configure can answer. A bot's username is
  discoverable, and without that check anyone who found yours could approve a
  destructive command on your machine. A late tap cannot reopen a settled
  question either — each message carries a token matched against the question
  actually in flight.

  Interactive runs only. A headless run — codeep review --fix, ACP, CI —
  has nobody to ask, and blocking one on an answer that cannot come would hang
  a pipeline. Those paths are untouched and still decide from
  agentConfirmation.

  The token goes in your OS keychain; the chat ID is ordinary config. Telegram
  necessarily sees the command, because you cannot judge what you are approving
  otherwise — which is why this is off by default.

Fixed

• The confirmation showed the binary, not the command. It read
  parameters.command, which is git where the truth is git status — asking
  someone to approve a command they had not been shown, which is the one thing
  this gate must not do. The same truncated string went to the phone. The audit
  record already joined the binary with its arguments; that is now what both
  use.

• A Telegram send that failed said nothing. A wrong chat ID was
  indistinguishable from a phone nobody picked up. Telegram's own words are now
  surfaced, and the failure people actually hit while setting this up is
  translated into what to do about it.

• The Telegram toggle wrote a value its own getter could not read. Its
  options were the strings 'true' and 'false' while the getter returned a
  boolean, so the setting reported "On" and read false immediately afterwards,
  forever. Every select in the settings list is now checked against the value it
  reads back.

All three were found by using it, not by testing it.