refactor(telegram-bot): remove dead polling/receivers classes left by Telegram.Bot 22.10 upgrade

[Vasar007]

Context

PR #320 bumped Telegram.Bot from 22.2.0 to 22.10.0.1 as part of Phase 1 / milestone v0.9.7 (plan 01-06). The upgrade removed several library types (IUpdateReceiver, QueuedUpdateReceiver, BlockingUpdateReceiver, DefaultUpdateReceiver) and the project's polling pipeline was migrated to call TelegramBotClientExtensions.ReceiveAsync on ITelegramBotClient directly.

At PR #320 merge time, the local *Receiver* / *ReceiverFactory* wrappers were deliberately stubbed and kept as dead code "for source compat / potential future use" rather than deleted in-line, to keep the upgrade PR focused. PR #320 description records the stubbing explicitly. That follow-up is this issue.

This is intentionally scheduled outside the active milestone v0.9.8 (Phase 2 — Test Coverage, Phase 3 — Agent-Testable Feedback Loop). It belongs to the backlog parking-lot tracked under .planning/ROADMAP.md → ## Backlog.

Scope — Files to Remove

All five files are mutually internal (no external consumers) and not registered in Sources/WebServices/ProjectV.TelegramBotWebService/Startup.cs after PR #320:

File	Type	Why dead
Sources/WebServices/ProjectV.TelegramBotWebService/v1/Domain/Polling/Receivers/AsyncUpdateReceiverBase.cs	abstract class	Comment in file (line 15) confirms IUpdateReceiver removed in 22.10; class no longer wired into the polling pipeline.
Sources/WebServices/ProjectV.TelegramBotWebService/v1/Domain/Polling/Receivers/AsyncBlockingUpdateReceiver.cs	concrete class	Only references AsyncUpdateReceiverBase; comment confirms BlockingUpdateReceiver removed in 22.10.
Sources/WebServices/ProjectV.TelegramBotWebService/v1/Domain/Polling/Receivers/AsyncQueuedUpdateReceiver.cs	concrete class	Only references AsyncUpdateReceiverBase; comment confirms QueuedUpdateReceiver removed in 22.10.
Sources/WebServices/ProjectV.TelegramBotWebService/v1/Domain/Polling/Factories/IBotPollingReceiverFactory.cs	interface	Comment in file (line 11) confirms the IUpdateReceiver abstraction is gone; interface "kept for potential future use".
Sources/WebServices/ProjectV.TelegramBotWebService/v1/Domain/Polling/Factories/BotPollingReceiverFactory.cs	concrete class	Sole implementer of IBotPollingReceiverFactory; no DI registration in Startup.cs.

The two parent directories (Polling/Receivers/, Polling/Factories/) become empty after deletion — also remove the directories.

Verification — Dead Code Confirmed

# 1. No external consumers — every match is mutually internal
$ grep -rn "BotPollingReceiverFactory\|IBotPollingReceiverFactory\|AsyncUpdateReceiverBase\|AsyncBlockingUpdateReceiver\|AsyncQueuedUpdateReceiver" Sources/ --include="*.cs" \
  | grep -v "\.Polling/Factories/\|\.Polling/Receivers/"
# (no output — all matches are internal to the two doomed directories)

# 2. No DI registration in Startup.cs
$ grep -n "BotPollingReceiverFactory\|AsyncBlockingUpdateReceiver\|AsyncQueuedUpdateReceiver\|AsyncUpdateReceiverBase" Sources/WebServices/ProjectV.TelegramBotWebService/Startup.cs
# (no output)

# 3. Active polling path builds ReceiverOptions inline + calls BotClient.ReceiveAsync directly
$ grep -A 15 "StartReceivingUpdatesAsync" Sources/WebServices/ProjectV.TelegramBotWebService/v1/Domain/Polling/BotPolling.cs
# Lines 49-61: constructs `new ReceiverOptions { ... }` then `_botService.BotClient.ReceiveAsync(...)`.

The new polling code in BotPolling.cs is the active replacement — already shipped on master under PR #320.

Active Code That Stays (do not touch)

• Sources/WebServices/ProjectV.TelegramBotWebService/v1/Domain/Polling/BotPolling.cs — active polling driver (uses new 22.10 API directly).
• Sources/WebServices/ProjectV.TelegramBotWebService/v1/Domain/Polling/Handlers/{IBotPollingUpdateHandler.cs,BotPollingUpdateHandler.cs} — IUpdateHandler impl, wired in Startup.cs line 73.
• Sources/WebServices/ProjectV.TelegramBotWebService/Options/BotPollingOptions.cs — config record, used by BotPolling.cs line 48.
• Sources/WebServices/ProjectV.TelegramBotWebService/v1/Domain/Receivers/{IProcessingResponseReceiver.cs,ProcessingResponseReceiver.cs} — different namespace (Receivers, not Polling.Receivers); unrelated to the upgrade; wired in Startup.cs line 66. Do not confuse with the doomed directory.

Acceptance Criteria

• All 5 files in the Scope table above are deleted.
• The two now-empty parent directories Polling/Receivers/ and Polling/Factories/ are removed.
• Sources/WebServices/ProjectV.TelegramBotWebService/ProjectV.TelegramBotWebService.csproj no longer references these paths (it does not today — files are picked up by SDK glob; verify after deletion).
• dotnet build Sources/ProjectV.sln -c Release is green on ubuntu-latest and windows-latest with TreatWarningsAsErrors=true.
• dotnet build Sources/ProjectV.Desktop.sln -c Release is green on windows-latest.
• dotnet test Sources/ProjectV.sln is green; F# tests via Tests/ProjectV.ContentDirectories.Tests/...fsproj --no-build are green.
• dotnet format Sources/ProjectV.sln --severity warn --verify-no-changes is green.
• No new warnings about unused usings around the deleted namespaces (ProjectV.TelegramBotWebService.v1.Domain.Polling.Receivers, ProjectV.TelegramBotWebService.v1.Domain.Polling.Factories).

Context Restoration Pointers — Read These When You Pick This Up

• PR phase(01-06): bump external SDKs (TMDbLib/Telegram.Bot/Google.Apis/RestSharp) for net10 #320 — Telegram.Bot 22.2.0 → 22.10.0.1 upgrade. Description records each migration decision and the explicit "kept for source compat" stub rationale. Merge SHA: 5b93e79794553b61078020c32bd3fd96c63ab946. Base: f3c87e25ccba5088ad3a532995b0edd0123aef42. Closes NET-01: Upgrade target framework from net8.0 to net10.0 #300, NET-02: Bump every NuGet package to the latest stable version compatible with net10.0 #301.
• Milestone v0.9.7 archive — .planning/milestones/v0.9.7-phases/01-dependency-solution-upgrades/01-06-PLAN.md + 01-06-SUMMARY.md (plan 01-06 covers the external-SDK bumps including Telegram.Bot).
• Phase 1 decision log — .planning/milestones/v0.9.7-phases/01-dependency-solution-upgrades/01-CONTEXT.md for the broader Phase 1 / D-NN decision context.
• Stub comments in the doomed files themselves — each file has a <remarks> block documenting the 22.10 API change and why the class was stubbed.
• Backlog parking-lot directory — .planning/phases/999.1-telegram-polling-dead-code/ (created by /gsd-capture --backlog 2026-05-18; contains BACKLOG-CONTEXT.md with the full restoration brief, plus .gitkeep; will hold CONTEXT.md / PLAN.md / etc. when the work is picked up via /gsd-discuss-phase 999.1 → /gsd-plan-phase 999.1).
• ROADMAP backlog entry — .planning/ROADMAP.md → ## Backlog → Phase 999.1 row, links back to this issue.

Why This is Deferred (Not Inline in v0.9.8)

Milestone v0.9.8 is scoped to Phase 2 (Test Coverage) + Phase 3 (Agent-Testable Feedback Loop). Deleting these 5 files is mechanical, has zero functional impact, and would be churn against the test-suite/E2E work in v0.9.8. Pick it up as a small standalone PR in v0.9.9 (or whenever convenient) — it shouldn't touch any other file.

Estimate

S — ~30 min including PR-template fields. Single PR, single tiny commit, runs CI matrix.

---

Captured via /gsd-capture --backlog on 2026-05-18 during the v0.9.7 → v0.9.8 milestone transition.

[Vasar007]

An additional note about Migration Guide from the official doc: https://telegrambots.github.io/book/migrate/Version-22.x.html