feat(operator): auto-register Telegram webhook, aws-sm:// secret refs

[chaodu-agent]

Summary

Two related additions requested after the last E2E test of oabctl apply
against a real Telegram bot deployment (#1283): registering the webhook was
still a manual curl setWebhook step, and the only way to reference a
Secrets Manager secret in spec.secrets was the verbose ECS-native
valueFrom ARN format.

1. Auto-register the Telegram webhook

apply now calls Telegram's setWebhook API directly when
/webhook/telegram is one of spec.ingress.paths and spec.secrets has a
TELEGRAM_BOT_TOKEN entry — no manual curl step needed after deploying a
bot. If spec.secrets also has TELEGRAM_SECRET_TOKEN, it's passed through
so Telegram signs every webhook request with it.

apply already succeeded (ECS task running, API Gateway → VPC Link →
Cloud Map → task all wired up, webhook URL printed)
          │
          ▼
  /webhook/telegram in spec.ingress.paths?
   └─ no ─────────────────────────────► skip (no-op)
   └─ yes
          │
          ▼
  TELEGRAM_BOT_TOKEN in spec.secrets?
   └─ no ─────────────────────────────► skip (no-op)
   └─ yes
          │
          ▼
  resolve TELEGRAM_BOT_TOKEN (+ TELEGRAM_SECRET_TOKEN if present)
  from Secrets Manager
          │
          ▼
  POST https://api.telegram.org/bot<token>/setWebhook
  { url: <printed-webhook-url>, secret_token: <optional> }
          │
     ┌────┴────┐
     ▼         ▼
   200 OK    error
     │         │
     ▼         ▼
  ✓ printed  ⚠ printed as a warning — apply still exits 0,
  webhook       provisioning already succeeded; register
  registered    manually with the printed URL instead

This is best-effort by design: the AWS-side provisioning is already done and
correct by the time this runs, so a Telegram API hiccup (bad token, network
blip) shouldn't roll any of that back or fail the whole command. LINE has no
setWebhook-equivalent API, so its URL still needs manual registration in
the LINE Developers console.

2. aws-sm://<secret-id>#<json-key> shorthand for spec.secrets

spec.secrets previously required the full ECS-native valueFrom format:

spec:
  secrets:
    TELEGRAM_BOT_TOKEN: "arn:aws:secretsmanager:us-east-1:123456789012:secret:oab/telegram/mybot-AC80TP:TELEGRAM_BOT_TOKEN::"

Now also accepts the same aws-sm://<secret-id>#<json-key> shorthand openab
itself uses for in-app secret refs in config.toml:

spec:
  secrets:
    TELEGRAM_BOT_TOKEN: "aws-sm://oab/telegram/mybot#TELEGRAM_BOT_TOKEN"

ECS has no knowledge of the aws-sm:// scheme, so oabctl translates it to
the ECS-native form before passing it to register_task_definition. A bare
secret name (not already an ARN) is resolved to its ARN via DescribeSecret
first, since ECS's valueFrom requires the full ARN whenever a JSON-key
suffix is present — a bare name only works without the suffix.

The two features are related: registering the webhook needs the actual
plaintext token value in-process (not just an ECS valueFrom reference), so
a new operator/src/secrets.rs module centralizes both resolution paths
(resolve_value_from for ECS, resolve_string for in-process use) on one
shared aws-sm:// URI parser, instead of duplicating the parsing logic.

Dependencies

Adds reqwest (default-features = false, rustls-tls + json only —
shares most of its TLS stack with what the AWS SDK crates already pull in
transitively) as the HTTP client for calling Telegram's API. No other new
dependencies.

Testing done

cargo build --release                        # clean
cargo clippy --all-targets -- -D warnings    # clean
cargo test --release                         # 26 passed; 0 failed

7 new unit tests: aws-sm:// URI parsing edge cases (missing #, empty
secret-id/json-key, non-aws-sm:// values pass through untouched) and
find_telegram_webhook's path/secret gating logic (fires only when both the
Telegram path and the bot token secret are present).

All verified on macmini per the project's build-offloading convention — not
run locally. Could not exercise the live Telegram API call end-to-end in
this PR (would require registering against a real bot and secret); the
webhook-URL-matching and secret-gating logic is unit tested, and the
Secrets Manager resolution path reuses the same GetSecretValue/
DescribeSecret calls already exercised live in #1283's E2E testing.

[chaodu-agent]

LGTM ✅ — Clean, well-guarded addition of two related features with solid test coverage and best-effort semantics.

What This PR Does

Eliminates two manual steps after oabctl apply deploys a Telegram bot: (1) calling curl setWebhook by hand, and (2) writing the verbose ECS-native Secrets Manager ARN format. Now apply auto-registers the Telegram webhook and spec.secrets accepts the shorter aws-sm://<secret-id>#<json-key> shorthand.

How It Works

A new operator/src/secrets.rs module centralizes aws-sm:// URI parsing and provides two resolution paths: resolve_value_from (translates to ECS-native valueFrom format, resolving bare secret names → full ARN via DescribeSecret) and resolve_string (fetches the actual plaintext for in-process use). ingress.rs gains register_telegram_webhook, gated on both /webhook/telegram being present in spec.ingress.paths and TELEGRAM_BOT_TOKEN existing in spec.secrets. Errors from the Telegram API are printed as warnings only — apply never fails on account of this step.

Findings

#	Severity	Finding	Location
1	🟢	Correct best-effort design — Telegram failure can't roll back provisioning	ingress.rs:170-228
2	🟢	Good URI parser validation — rejects empty secret-id and empty json-key	secrets.rs:14-26
3	🟢	Solid unit test coverage for gating logic and parsing edge cases (7 tests)	secrets.rs, ingress.rs
4	🟢	reqwest added with minimal feature flags, shares TLS stack with existing AWS SDK crates	Cargo.toml
5	🟢	README documentation is thorough — explains both formats, includes a complete minimal manifest	README.md

What's Good (🟢)

• Best-effort semantics: The webhook registration correctly runs after all AWS provisioning succeeds and communicates failure via a non-fatal warning. This matches the PR description's design philosophy perfectly.
• Shared parser: Having one parse_aws_sm_uri used by both resolve_value_from (ECS direction) and resolve_string (in-process direction) avoids duplicate parsing logic — a good abstraction boundary.
• Gating logic: find_telegram_webhook requires both the path and the secret to be present before firing — neither false positives nor crashes for LINE-only bots or bots without a token configured.
• Error context: Pervasive use of anyhow::Context means failures propagate with clear breadcrumbs (which secret failed, which step in the resolution).
• Documentation: The README section covers both secret formats with annotated YAML, explains ECS's ARN-suffix requirement, and includes a copy-pasteable minimal manifest.

Baseline Check

• PR opened: 2026-07-04T03:02:19Z (same day)
• Main already has: apply.rs builds ECS secrets from spec.secrets using a simple .map() passthrough; no aws-sm:// handling; no Telegram webhook registration; no secrets.rs module
• Net-new value: Full aws-sm:// URI resolution for spec.secrets (both ECS-native and plaintext paths), and automatic Telegram setWebhook call gated on path + secret presence