refactor(api): extract the Telegram Bot adapter into its own package

[setkyar]

The channel-neutral contracts already live in @wateaminbox/shared, but the
Telegram provider sat inside apps/api, so nothing stopped it from reaching for
application internals. This moves it to @wateaminbox/adapter-telegram, whose
only imports are @wateaminbox/shared, node:crypto, and bun:test.

The cut

adapter.ts, api.ts, and normalize.ts move unchanged — they had no
app-internal imports to begin with. Only transport.ts was coupled, through
three functions, so it now takes injected ports:

Port	Host-side work
resolveOutboundContext	credential read, conversation lookup
resolveAttachmentUrl	media presigning

Both are bound in apps/api/.../telegram-bot/ports.ts and injected by the
registry, which remains the composition root. Tenant database and media storage
knowledge stays with the application; Bot API knowledge stays in the package.

Two things beyond a straight move:

• parseTelegramThreadTarget moves into the package. The
  <chatId>[:thread:<topicId>] encoding is Telegram's, even though the host owns
  the column that stores it.
• The local-failure protocol is now explicit. TELEGRAM_LOCAL_FAILURE_CODES
  and TelegramLocalFailureError are exported, and the host raises from that
  closed set rather than throwing bare strings that classifyTelegramSendFailure
  happened to match. The message is still the code, so classification is
  unchanged — anything outside the set degrades to uncertain and strands a send
  instead of failing it, which is why the set is closed.

Merging main

Main's credential-key handling (#391, #393) landed on the three files this branch
moved, and git followed the renames — carrying
services/channel-credential.service.js imports into a package that may not have
them. Both intents are kept, re-plumbed across the boundary:

• Ingress. The adapter cannot recognise an application error type, so it takes
  an isCredentialUnavailable predicate alongside the resolver it already took;
  the registry supplies (error) => error instanceof ChannelCredentialKeyError.
  The original instance is rethrown untouched, so channel-ingress.ts keeps
  main's instanceof check unchanged — which matters, because that route is
  provider-generic and must not learn about provider packages.
• Sending. telegram_credential_key_unavailable joins the closed code set, so
  classification needed no new branch; the translation lives in the host's
  readBotToken. Missing it anywhere would let the raw error reach
  classifyTelegramSendFailure as unrecognised and be called uncertain — never
  retried — which is the bug main fixed. The package test asserts the
  classification and the ports integration test asserts the translation, by
  storing a credential under a retired key version.

New test coverage

resolveOutboundContext is the only logic this refactor rewrote, and it had no
test before — transport.ts's only test covered failure classification. The new
ports.integration.test.ts covers the forum-topic split and six refusals that
must each arrive as a specific code: malformed thread id, unmapped thread,
archived conversation, paused account, another account's conversation, missing
credential, and a credential under a retired key version.

Workspace wiring

• apps/api dependency, root typecheck chain (the package must build before
  tsc or apps/api cannot resolve its dist types), and a knip.json entry.
• scripts/run-tests.sh enumerates test directories explicitly, so the moved
  tests would have silently left CI without a new line.
• scripts/run-integration-tests-ts.sh gains a synthetic, non-secret credential
  keyring, because the adapter reads credentials through the configured cipher.

Testing

Check	Result
bun run build	8/8
bun run typecheck	clean
packages/adapter-telegram tests	25 pass
apps/api unit tests	947 pass, 0 fail
TS integration suite	121 files, 597 pass, 0 fail
lint / format / knip	clean

The ports integration test was mutation-checked: inverting the account-status
guard and dropping the credential-key translation each fail it.

Not included

WhatsApp stays in apps/api: its transport depends on NATS, message formatting,
the command outbox, and session state, and its normalizer imports MessageEvent
from lib/nats. Extracting it means untangling the worker protocol.