feat: sync architecture upgrades from omnicloud-support-agent

[BukeLy]

Summary

从 omnicloud-support-agent 同步通用架构改进，提升系统可靠性、安全性和用户体验。

主要改进

改进项	原状态	新状态	效果
SQS队列	标准队列	FIFO队列	保证同一会话内消息顺序
Node.js	默认版本	20+	MCP undici 依赖兼容
Docker HOME	/root	/tmp	MCP auth 文件写入权限
Webhook验证	无	HMAC验证	防止伪造请求
打字指示	单次	持续循环(4s)	长请求时保持反馈
Markdown转换	基础	完整管道	Telegram格式正确显示
本地命令	静态文本	handler支持	可扩展性提升

新增功能

• /debug 命令：下载当前会话的 session 文件
• /start 命令：私聊欢迎消息
• message_time 字段透传到 Agent Server

文件变更

• template.yaml: 添加 FIFO 队列配置、TelegramWebhookSecret 参数、Producer IAM 权限扩展
• Dockerfile: 升级 Node.js 20+、修改 HOME 为 /tmp、配置 npm 缓存
• handler.py: FIFO 消息支持、webhook 验证、handler 命令处理
• consumer.py: 持续打字指示、Markdown 转换管道
• config.py: LocalCommand dataclass 支持
• security.py: 添加 verify_telegram_secret_token 函数
• requirements.txt: 添加 telegramify-markdown 依赖

破坏性变更

⚠️ SQS 队列从标准升级为 FIFO：部署时需要注意：

1. 现有队列需要先删除再重新创建（SAM 会自动处理）
2. 确保队列中的消息已处理完毕再部署

Test plan

• 验证 SAM 模板部署成功
• 验证 Telegram webhook 验证功能（配置 secret 后）
• 验证 FIFO 队列消息顺序
• 验证 /debug 命令输出 session 文件
• 验证持续打字指示在长请求时显示
• 验证 Markdown 格式在 Telegram 中正确显示

[BukeLy]

Code review

Found 1 issue:

1. FIFO queue deduplication ineffective due to random UUID in MessageDeduplicationId

The MessageDeduplicationId includes a random UUID component, which defeats the purpose of FIFO queue deduplication. When a message is retried (e.g., due to Lambda timeout), a new UUID is generated, causing SQS to treat it as a different message.

dedup_id = f"{chat_id}-{message_body.get('message_id')}-{uuid.uuid4().hex[:8]}"

The deduplication ID should be deterministic based on message content. Suggested fix:

dedup_id = f"{chat_id}-{message_body.get('message_id')}"

Stateless-FileSystem-Agent/agent-sdk-client/handler.py

Lines 91 to 93 in c11dd9c

	message_group_id = f"{chat_id}:{thread_id}"
	dedup_id = f"{chat_id}-{message_body.get('message_id')}-{uuid.uuid4().hex[:8]}"

---

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[BukeLy]

Correction

After further analysis, the issue raised above is not valid. The random UUID in MessageDeduplicationId is intentional and correct.

Reasoning:

The purpose of FIFO queue here is to guarantee message ordering within the same session (via MessageGroupId), not to deduplicate retries.

If a Lambda times out and SQS retries the message, we want it to be reprocessed so the user eventually gets a response. Using a deterministic dedup ID would cause SQS to reject the retry within 5 minutes, leaving the user without a response.

With random UUID (correct):
- 1st attempt: Lambda timeout → no response
- 2nd attempt (retry): new UUID → reprocessed → user gets response ✓

With deterministic ID (wrong):
- 1st attempt: Lambda timeout → no response  
- 2nd attempt (retry): same ID → SQS rejects as duplicate → user never gets response ❌

Apologies for the incorrect review.

---

🤖 Generated with Claude Code