Azure App Service rollout for /subscribe telegram pattern

[TaprootFreak]

Tracking issue for the Azure-side rollout that goes alongside #175 (replace TELEGRAM_CHAT_ID with self-service /subscribe and a persisted TELEGRAM_GROUPS_JSON file).

The code change is repo-local; the deploy needs three Azure App Service config changes per environment that cannot live in the repo.

Per environment (DEV + PRD)

1. Add TELEGRAM_GROUPS_JSON app setting

Set the env var to a path inside the persistent storage mount, e.g.:

TELEGRAM_GROUPS_JSON = /home/data/telegram.groups.json

(The exact path can be wherever Azure Files is mounted in the container — adjust to the existing convention.)

2. Mount Azure Files persistent storage

Without persistence the subscriber list is lost on every container restart. Use Azure Files in the App Service "Path mappings" so the groups file survives.

If a persistent mount already exists for other state, just reuse it for the groups file path.

3. Remove TELEGRAM_CHAT_ID (optional cleanup)

The new code reads only TELEGRAM_GROUPS_JSON. The existing TELEGRAM_CHAT_ID setting becomes inert and can be deleted to avoid confusion.

Migration of existing recipients

The current TELEGRAM_CHAT_ID value identifies the chat that has been receiving alerts so far. After deploy the bot starts with an empty subscriber list — that chat needs to be re-registered:

• Easiest: in the existing chat, send /start (or /subscribe) to the bot. The bot's polling picks it up and writes the chat-id into groups.json automatically.
• Alternative: seed the file once via Azure Storage Explorer:

  {"apiVersion":"1.0.0","createdAt":<unix-ms>,"updatedAt":<unix-ms>,"groups":["<existing-chat-id>"]}

Repeat per environment (the DEV chat-id is a private chat, the PRD chat-id is a group — both need re-registration in their own environment).

Verification

After deploy:

• Container log shows Telegram bot polling started (1 subscriber(s)) (or 0 if unmigrated)
• /start in a fresh chat with the bot receives You are now subscribed. Use /unsubscribe to stop.
• Trigger a real alert path → message arrives in every registered chat
• /unsubscribe → bot replies You are not subscribed anymore. and removes the chat from groups.json

Out of scope

• Token rotation (DEV and PRD already use distinct bots — no shared-token conflict like the d-EURO monitoring case)
• New BotFather setup