#18254: add /update chat command for Telegram git updates

Add a new /update slash command that pulls the latest code from git and rebuilds, then triggers a gateway restart. Gated behind commands.update config (default: false) like /restart. https://claude.ai/code/session_01Ef5pXEVZNLJ7qUt2zhxTiG ## Summary Describe the problem and fix in 2–5 bullets: - Problem: - Why it matters: - What changed: - What did NOT change (scope boundary): ## Change Type (select all) - [ ] Bug fix - [ ] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [ ] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes # - Related # ## User-visible / Behavior Changes List user-visible changes (including defaults/config). If none, write `None`. ## Security Impact (required) - New permissions/capabilities? (`Yes/No`) - Secrets/tokens handling changed? (`Yes/No`) - New/changed network calls? (`Yes/No`) - Command/tool execution surface changed? (`Yes/No`) - Data access scope changed? (`Yes/No`) - If any `Yes`, explain risk + mitigation: ## Repro + Verification ### Environment - OS: - Runtime/container: - Model/provider: - Integration/channel (if any): - Relevant config (redacted): ### Steps 1. 2. 3. ### Expected - ### Actual - ## Evidence Attach at least one: - [ ] Failing test/log before + passing after - [ ] Trace/log snippets - [ ] Screenshot/recording - [ ] Perf numbers (if relevant) ## Human Verification (required) What you personally verified (not just CI), and how: - Verified scenarios: - Edge cases checked: - What you did **not** verify: ## Compatibility / Migration - Backward compatible? (`Yes/No`) - Config/env changes? (`Yes/No`) - Migration needed? (`Yes/No`) - If yes, exact upgrade steps: ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: - Files/config to restore: - Known bad symptoms reviewers should watch for: ## Risks and Mitigations List only real risks for this PR. Add/remove entries as needed. If none, write `None`. - Risk: - Mitigation: <!-- greptile_comment --> <h3>Greptile Summary</h3> Adds a new `/update` chat command that pulls the latest code from git, rebuilds, and optionally triggers a gateway restart. The command is gated behind `commands.update` config (default: `false`), matching the existing `/restart` pattern. The implementation correctly follows existing conventions: authorization checks, config gating, error handling, and SIGUSR1-based restart. All supporting config (Zod schema, type definition, help text, labels) is consistently wired up across 7 files. - New file `commands-update.ts` implements the handler, reusing existing `runGatewayUpdate` and `scheduleGatewaySigusr1Restart` infrastructure - Config additions (`commands.update`) are consistent across types, Zod schema, labels, and help - Command registration in `commands-registry.data.ts` and handler list in `commands-core.ts` follow existing patterns - **Issue found**: The restart is triggered even when the update reports "already up to date" (no version change), causing unnecessary gateway downtime <h3>Confidence Score: 3/5</h3> - Generally safe to merge with one logic issue that causes unnecessary restarts when already up to date - The PR correctly follows existing patterns and is properly gated behind config. However, it has a logic bug where the gateway restart is triggered even when the code is already up to date, causing unnecessary downtime. The overall structure is sound and the security model (auth check, config gate) is correctly implemented. - `src/auto-reply/reply/commands-update.ts` - restart logic should check whether the version actually changed before scheduling a restart _{Last reviewed commit: bcd1c5b} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->