fix(telegram): drop ppid watchdog check; redirect bun install stdout to stderr

Two v0.0.5/0.0.6 regressions causing the plugin to fail at startup:

1. The orphan watchdog's process.ppid !== bootPpid check false-fires when the
   bun-run/shell wrapper exits or execs during normal startup and we get
   reparented to init — plugin self-terminates ~5s after launch. Stdin-close
   alone is the correct signal: the kernel closes the MCP pipe on any CLI
   death regardless of intermediate wrappers, so the ppid check was both
   unnecessary and harmful. (#1467; also the actual cause of #1459 item 3
   and likely #1425.)

2. 'bun install --no-summary' in the start script writes to stdout, which is
   the MCP JSON-RPC transport. The harness sees non-JSON bytes during the
   handshake and drops the connection ('Failed to connect'). Redirect install
   output to stderr. (#1470; also explains #1425 on Windows.)

external_plugins/telegram/server.ts

@@ -660,16 +660,14 @@ process.on('SIGTERM', shutdown)
 process.on('SIGINT', shutdown)
 process.on('SIGHUP', shutdown)
 
-// Orphan watchdog: stdin events above don't reliably fire when the parent
-// chain (`bun run` wrapper → shell → us) is severed by a crash. Poll for
-// reparenting (POSIX) or a dead stdin pipe and self-terminate.
-const bootPpid = process.ppid
+// Orphan watchdog: belt-and-suspenders for the stdin 'end'/'close' handlers
+// above. Stdin is the MCP transport pipe inherited straight from the CLI; the
+// kernel closes it on any CLI death (clean, crash, SIGKILL, OOM) regardless of
+// intermediate wrappers. A ppid-change check used to live here but it
+// false-fires when the bun-run/shell wrapper exits or execs during normal
+// startup and we get reparented to init.
 setInterval(() => {
-  const orphaned =
-    (process.platform !== 'win32' && process.ppid !== bootPpid) ||
-    process.stdin.destroyed ||
-    process.stdin.readableEnded
-  if (orphaned) shutdown()
+  if (process.stdin.destroyed || process.stdin.readableEnded) shutdown()
 }, 5000).unref()
 
 // Commands are DM-only. Responding in groups would: (1) leak pairing codes via