…(C2)

Adds gateway/platforms/msteams/auth.py with three CredentialProvider
implementations and a factory that reads PlatformConfig.extra:

- SecretCredentialProvider — MSAL client-secret flow.  Default when
  MSTEAMS_AUTH_TYPE is unset or "secret".
- CertificateCredentialProvider — MSAL certificate flow for federated
  auth.  Reads a PEM containing both private key and cert body; honours
  a send_public_cert opt-in for subject-name / issuer trust setups.
- ManagedIdentityCredentialProvider — azure-identity ManagedIdentityCredential
  for deployments on Azure compute (App Service, AKS, Container Apps).
  Surfaces non-Azure misconfiguration as AuthError with a clear message.

All three providers share the same get_token(scope) surface and cache
tokens with a 5-minute early-refresh window, so Bot Framework and Graph
calls hit the network once per token lifetime.  asyncio.Lock per scope
coalesces concurrent refreshes.  MSAL / azure-identity synchronous calls
run via asyncio.to_thread so the gateway event loop stays free.

Scopes are exposed as BOT_FRAMEWORK_SCOPE and GRAPH_SCOPE constants so
callers in C3 (adapter) and C4 (Graph client) import them rather than
typing the URLs by hand.

Tests: 21 cases covering factory branching, PEM + thumbprint handling,
cache hits, refresh boundary, per-scope isolation, MSAL error surfacing,
concurrent-request coalescing, and MI failure modes.  All pass alongside
the C1 wiring tests.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Replaces the C1 stub adapter with the real Bot Framework webhook loop:

- Dedicated aiohttp server on config port/path (default 3978, /api/messages)
  with a scoped platform lock, graceful shutdown, and a /health probe.
- Incoming Activity JWT validation via JwtTokenValidation +
  SimpleCredentialProvider.  Federated-auth bots validate the same way
  because inbound tokens are signed by Microsoft's public JWKS —
  independent of how outbound tokens are minted.
- Activity → MessageEvent translation.  Conversation type maps to
  chat_type (personal→dm, channel→channel, groupChat→group); AAD object
  id fills user_id; channel_data.channel.id fills thread_id; team id is
  parked in chat_id_alt for later Graph calls.  @mention stripping via
  <at> tag detection + plain-@ prefix with app-id fallback.
- Policy gates mirroring openclaw:
    * dm_policy: pairing (default, hands off to Hermes pairing),
      allowlist (requires allow_from membership), open, disabled.
    * group_allow_from for channels / group chats.
    * require_mention with per-channel free_response_channels bypass.
    * Per-team and per-channel overrides layered onto the adapter
      defaults via PlatformConfig.extra['teams'][team_id].channels[...].
- markdown_to_teams_html converter: bold / italic / inline code /
  fenced code blocks / links / simple bullet & numbered lists.  HTML-
  escapes the input first so LLM-emitted <script> stays inert.  Emits
  text suitable for outgoing activities with textFormat="xml".
- Outbound send / send_typing: compose {serviceUrl}/v3/conversations/
  {chat_id}/activities, Bearer token from CredentialProvider for
  BOT_FRAMEWORK_SCOPE, retryable flag on transport + 5xx failures.
- service_urls.json sidecar under HERMES_HOME/msteams: every inbound
  activity records its serviceUrl so the standalone _send_msteams
  helper (cron, send_message outside the gateway) can reach the same
  conversation without the gateway process running.
- Credential provider is built lazily in connect() so the adapter is
  constructible for status probes and tests even when credentials are
  missing.  Construction errors surface as a fatal state with a
  msteams_auth error code.

Tests: 43 new cases for markdown shapes, mention stripping, URL
composition, effective-policy layering, every dm_policy branch,
require_mention + free_response_channels, group_allow_from,
_build_event for DM / channel / group, serviceUrl persistence,
outbound happy path, serviceUrl-missing error, AuthError propagation,
5xx retryable classification, send_typing shape, and connect() failure
modes.  Adjacent suites (slack, mattermost, allowlist, config,
channel_directory, delivery) still green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

New gateway/platforms/msteams/graph.py wraps msgraph.GraphServiceClient
with the narrow set of operations the adapter needs:

- fetch_channel_messages(team_id, channel_id, top) — oldest-first recent
  history, for later channel-prepend behaviour.
- resolve_user(aad_object_id) — display name, email, job title.
- search_users_by_display_name(prefix, top) — @mention search;
  single-quote-escapes the prefix before substituting into the OData
  filter.
- list_joined_teams + list_channels — enumeration helpers for future
  channel-directory integration.
- download_hosted_content — pulls bytes for inline channel attachments.
- upload_to_sharepoint — simple PUT upload to a SharePoint drive folder,
  returns the resulting webUrl.  Chunked/resumable upload (createUploadSession
  for >4 MB) is out of scope for the MVP.

Every method catches Graph SDK errors, logs the failure with a stable
action label, and returns an empty / None value.  A Graph outage never
takes the Bot Framework event loop down — the agent sees degraded
features, not a dead adapter.

Authentication: a _HermesTokenCredential thin wrapper adapts the
CredentialProvider from auth.py to azure.core.credentials_async's
AsyncTokenCredential contract, so the same provider drives both Bot
Framework (BOT_FRAMEWORK_SCOPE) and Graph (GRAPH_SCOPE) calls through
one shared cache.  The Graph client is built lazily on first use and
closed alongside the credential provider during disconnect().

Adapter integration:

- connect() instantiates a GraphClient; disconnect() closes it.
- _build_event records channel→team mapping in _team_ids_by_chat so
  subsequent get_chat_info / SharePoint upload calls can address the
  channel without the caller passing a team id.
- get_chat_info for channels now queries Graph's list_channels for the
  parent team and merges display_name / description / membership_type.
  DMs and missing-Graph cases fall back to the pre-existing stub.
- fetch_channel_history, resolve_user, and upload_channel_file helpers
  expose the Graph wrapper to future C5 code paths (FileConsent card,
  channel attachment cards).  upload_channel_file namespaces per chat
  so uploads from different channels don't collide on filename.

Tests: 22 new cases covering _HermesTokenCredential delegation and
scope requirement, _attr helper (attribute + dict + default), message
dict projection, resolve_user happy + error paths, user search with
quote-escaping, channel history newest→oldest reversal, team /
channel enumeration, hosted-content download and failure, adapter
get_chat_info with + without Graph, history limit propagation, upload
site-id gating, and Graph lifecycle in connect/disconnect.  All 101
msteams tests (C1+C2+C3+C4) remain green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Completes the MS Teams integration for openclaw feature parity.

New gateway/platforms/msteams/cards.py with builders for:

- Adaptive Cards: schema-agnostic wrapper so agent code owns the layout
  while the adapter just transports the attachment.
- FileConsentCard + FileInfoCard: the DM upload consent flow.  Every
  consent card carries a stable upload_id the invoke handler uses to
  match the accept/decline response.
- file.download.info attachment: channel / group file card wired to a
  SharePoint webUrl — what Teams renders as a proper file tile.
- markdown_to_teams_html: the markdown→Teams-HTML converter moved from
  the adapter so it has its own test surface and both cards and plain
  sends can reuse it.  The adapter re-exports it for backward compat.

Adapter integration:

- send_document / send_image_file / send_video route by chat type.  DM
  → FileConsent (buffered in _pending_uploads, keyed by upload_id, PUT
  to the uploadInfo URL on accept, follow-up FileInfoCard so the user
  sees the file inline).  Channel / group → SharePoint upload via the
  Graph client + file.download.info attachment.  Decline drops the
  staged upload; unknown upload_ids are accepted (200) but ignored.
- send_image on a channel with SharePoint configured now downloads the
  image URL and re-uploads it through SharePoint for a native file
  tile instead of a plain hyperlink.
- _handle_messages routes fileConsent/invoke activities to the new
  _handle_file_consent_invoke method; everything else keeps the 200
  ack to stop Teams retrying.

Federated-auth wizard (hermes_cli/gateway.py):

- New _setup_msteams delegates core prompts to _setup_standard_platform
  then branches on MSTEAMS_AUTH_TYPE.  Federated users pick between a
  certificate path + thumbprint or Azure Managed Identity with an
  optional user-assigned client id.  Routed from the main setup switch.

Docs:

- New website/docs/user-guide/messaging/msteams.md: Azure registration,
  secret/certificate/Managed Identity walk-through, Bot Framework
  portal setup, Teams app manifest template with RSC permissions,
  full env var reference, per-team / per-channel override snippet,
  troubleshooting (JWT failure, missing SharePoint site, stale upload
  URL, Managed Identity outside Azure).
- index.md: platform feature table + architecture diagram + toolset
  table + Next Steps link all updated for MS Teams.
- environment-variables.md: every MSTEAMS_* variable documented.
- README.md messaging row, AGENTS.md platform adapter listing updated.

Tests: 15 new cases for card shapes (Adaptive, FileConsent, FileInfo,
file.download.info), file type inference for extension-less names,
markdown re-export through the adapter, DM send_document → FileConsent
payload shape + staged bytes, invoke accept → PUT + FileInfoCard
follow-up, invoke decline → no upload, unknown upload_id → silent 200,
channel send_document → SharePoint upload + file.download.info
attachment, missing site_id clear error, missing file clear error,
invoke routing from _handle_messages.  Combined with C1–C4, the
msteams suite now runs 116 cases green.  Adjacent suites (slack,
mattermost, allowlist, config, channel_directory, delivery, api_server)
remain green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

C5 added a _setup_msteams() helper to hermes_cli/gateway.py's platform
list, but missed the parallel _GATEWAY_PLATFORMS list in
hermes_cli/setup.py — the checklist the default `hermes setup` wizard
shows.  With only gateway.py updated, MS Teams appeared under
`hermes gateway` but was absent from the main setup flow, which is
where most users land first.

Adds a fresh _setup_msteams() in setup.py that mirrors the gateway.py
wizard (App ID + tenant, secret/federated auth branch, allowlist,
home conversation) and plugs it into _GATEWAY_PLATFORMS between
Mattermost and WhatsApp so the numbering and grouping match docs.

Updates ADDING_A_PLATFORM.md §13 to call out that both lists must be
kept in sync — the two checklists serve different wizards and it's
easy to miss the second one.

Tests: existing MS Teams suite (116 cases) still green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Every inbound message funnels through
gateway.run._run_agent -> tools_config._get_platform_tools, which
indexes PLATFORMS[platform]["default_toolset"].  PLATFORMS lives in
hermes_cli/platforms.py — a registry I missed in the C1 checklist.
Without the msteams entry the first real Teams activity crashed with
KeyError: 'msteams' right after the pairing flow finished, so the user
saw "Sorry, I encountered an error (KeyError)" instead of an agent
response.

Adds an ordered entry mapping msteams → hermes-msteams so the
platform_toolsets fall-back in tools_config picks up the toolset that
C1 already defined in toolsets.py.

Also appends §6b to ADDING_A_PLATFORM.md so future platform-adders
don't retrace this trap.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…rding

Bundles everything needed to run the full Hermes agent image with the
MSTeams adapter exposed:

- docker/compose.msteams.yml: builds the repo Dockerfile (which pulls
  the [all] extra, including [msteams]), mounts state into
  ./hermes-data, publishes 3978 (MSTeams webhook), 8642 (OpenAI API),
  8644 (webhook receiver).  extra_hosts pins host.docker.internal to
  the host gateway so LM Studio / Ollama reachable from the host also
  works on Linux.
- docker/.env.msteams.example: skeleton for Azure credentials, auth
  type, access policy, SharePoint, and the model provider secret.
- docker/entrypoint.sh: converted CRLF → LF line endings.  Windows
  checkouts were producing "exec entrypoint.sh: no such file" inside
  the image because the Linux kernel tried to exec /bin/bash\r.
- .gitattributes: forces *.sh (especially docker/entrypoint.sh) to
  stay LF so the regression can't recur.
- .gitignore: excludes docker/.env.msteams (holds real secrets) and
  docker/hermes-data/ (container volume) from the repo.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Observed during MSTeams onboarding: the hermes setup wizard silently
accepted a whole Azure 'Certificates & secrets' page pasted into the
client-secret prompt, saving the concatenation of Secret ID + label +
Secret Value (85 chars) to HERMES_HOME/.env.  The adapter then sent
that blob to MSAL, which returned AADSTS7000215 ("secret is not the
value"), and the gateway looped on send failures with the correct-
looking credentials in env.

Azure client secret Values are ~40 chars, single-line, no whitespace.
The wizard now strips leading/trailing whitespace and refuses to save
any input that contains internal whitespace OR exceeds 72 chars,
printing a warning that points to the right field in Azure Portal.
Valid secrets fall through unchanged.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

When 'hermes setup' finishes inside a container, the wizard's
existing 'Restart the gateway to pick up changes?' branch bails out
silently — systemd_restart/launchd_restart don't apply to pid 1 of a
container, and the running gateway process keeps serving adapters
with the os.environ snapshot it was started with.  The credentials
the wizard just wrote to HERMES_HOME/.env are not picked up until the
container itself is restarted.  Users hit this MSTeams-first
integration and found the bot silent after a successful setup flow.

Adds a single-paragraph hint printed right after 'Setup complete!'
when the user is (a) inside a container per hermes_constants.is_container,
and (b) just configured a messaging platform.  Uses the container
hostname (which Docker/Podman set to the short id) to produce a
copy-pasteable 'docker restart <id>' command.

No effect outside containers or when the gateway section was skipped.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The C3 adapter stopped at text — attachments on the incoming Activity
were not parsed, so vision-capable models (Gemma 4 31B, GPT-4o, etc.)
never got the bytes when a user dropped an image into a Teams chat.
Symptom: bot silently answered as if no image were present.

Now _build_event (made async) calls a new _extract_image_attachments
helper that:

- walks activity.attachments, matches content_type starting with
  "image/" and reads content_url (tolerating both the snake_case
  botbuilder-schema shape and the raw camelCase dict the SDK sometimes
  hands through);
- mints a single Bot Framework bearer token from the adapter's
  CredentialProvider and reuses it for every download in the activity
  — Teams-hosted attachment URLs reject anonymous GETs;
- caches each payload via cache_image_from_bytes so the agent sees
  local file paths on MessageEvent.media_urls, with an extension
  derived from contentType (falls back to .jpg for exotic types);
- sets MessageType.PHOTO so the vision pipeline actually runs;
- logs and skips individual download failures so one broken image
  never blocks the accompanying text.

Text-only and image-only messages both dispatch now; text + image
dispatches as PHOTO with the caption.  Channel attachments delivered
as hosted-content refs (bearer-less SharePoint stubs) still flow
through the Graph helper added in C4 — that remains behind an explicit
sharepoint_site_id + admin-consented permissions and is unchanged.

Helpers _attr_or_key / _camel / _snake handle the shape mismatch
between Activity class attributes and raw dict fallbacks.

Tests: 3 new cases covering happy-path download + bearer-token use,
image-only dispatch (no text), and graceful fallback when the
download returns 403.  Full MSTeams suite at 119/119.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Previous commit only recognised image attachments with
contentType starting with "image/" — the classic Direct Line /
emulator shape.  Teams web & desktop clients deliver pasted user
images differently: the file is uploaded to OneDrive/SharePoint
under "Microsoft Teams Chat Files", then sent as a
"application/vnd.microsoft.teams.file.download.info" attachment
with:

  content.downloadUrl = https://<tenant>.sharepoint.com/.../download.aspx
                        ?UniqueId=...&tempauth=v1.<signed-token>
  content.fileType    = png | jpg | jpeg | gif | webp

The tempauth in the URL is a short-lived SAS-like pre-authenticated
token.  Adding an Authorization: Bearer header — as used for the
classic image/* path — causes SharePoint to reject the request.

_extract_image_attachments now branches on contentType:
- image/*  → keeps the Bot Framework bearer-token download
- file.download.info  → inspects content.fileType, only pulls when
  it's one of the image extensions, and downloads the tempauth URL
  with NO Authorization header
- anything else (PDF/DOCX etc.) falls through to the agent's
  generic file handling

Mimetype is derived from fileType for the SharePoint path so the
agent's vision pipeline still sees "image/png" (etc.) rather than
the opaque "application/vnd.microsoft.teams.file.download.info".

Diagnostics added in the previous patch (raw-JSON attachments dump)
are removed — this fix was informed by them, the protocol shape is
now known and the dump would be noise on every image hereafter.

Tests: 2 new cases — one for the SharePoint/tempauth happy path
verifying no Authorization header leaks, one for a PDF with
fileType=pdf verifying the image pipeline skips it.  MSTeams suite
at 121 green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Adds a thin convention on top of build_adaptive_card: a bold
question TextBlock + Input.ChoiceSet + single Action.Submit.
Renders in Teams as a native poll UI.

- is_multi_select toggles the ChoiceSet between radio and checkbox
  behaviour; the agent keeps the full card JSON for anything more
  elaborate.
- submit_data is merged into the Action.Submit data bag so the
  invoke handler can identify which poll the vote belongs to.
- Choice values equal the visible titles — for opaque ballot-style
  voting, callers should build the Adaptive Card by hand.

Tests: 3 cases covering single-select default shape, multi-select
with custom submit title + poll correlation, and the empty-options
ValueError.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…delivery

Replaces the C1 stub with a self-contained implementation that runs
without the Hermes gateway process — required for cron jobs that
fire while the gateway is stopped and for send_message tool calls
outside the gateway event loop.

Flow:
1. Look up the target conversation's serviceUrl in the sidecar
   $HERMES_HOME/msteams/service_urls.json (populated by every inbound
   activity the live adapter handles).  An unknown chat_id fails
   fast with a clear message — the bot has never seen this
   conversation, so there is no route to it.
2. Mint a Bot Framework bearer token via msal.ConfidentialClientApplication
   using MSTEAMS_APP_ID + MSTEAMS_APP_PASSWORD + MSTEAMS_TENANT_ID
   (env wins; PlatformConfig.extra is the fallback).  Client-secret
   auth only — certificate and Managed Identity paths remain on the
   live adapter where the long-lived CredentialProvider lives.
3. Convert the markdown body to Teams HTML via cards.markdown_to_teams_html
   so cron deliveries match the formatting of adapter-authored sends.
4. POST {serviceUrl}/v3/conversations/{chat_id}/activities with
   textFormat=xml; thread_id (when supplied) becomes replyToId so
   cron results land in the triggering thread.

Non-200 status codes and MSAL error payloads are surfaced verbatim
in the returned error — operators debugging silent cron delivery
now see the exact Azure trace id / status rather than "not
implemented".

Tests: 7 cases — happy path with MSAL args + POST shape asserted,
reply-in-thread, unknown chat_id, missing credentials, missing
sidecar, MSAL failure (AADSTS), 503 retry signal.  No real network.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Tenants that restrict anonymous access to Teams hosted-content URLs
returned 403/410 on the classic image/* GET path, causing the vision
pipeline to see zero bytes even though the activity still named the
attachment.  The Graph wrapper we shipped in C4 knows how to pull
the same bytes through
/teams/{team}/channels/{channel}/messages/{msg}/hostedContents/{id}/$value
— but the adapter wasn't routing failed direct downloads there.

_extract_image_attachments now:

- Captures team + channel ids from activity.channel_data and the
  activity.id as a one-shot Graph context.
- On a direct download failure (non-200 status or transport error),
  parses the hostedContents id out of the contentUrl via a new
  _parse_hosted_content_id helper.
- When team/channel/message/hostedContentId are all present AND the
  adapter has an initialised GraphClient, calls
  GraphClient.download_hosted_content and proceeds with the bytes.
- SharePoint file.download.info URLs have no /hostedContents segment,
  so the fallback cleanly no-ops for them (tempauth is their auth
  model; there's no Graph equivalent path).

DMs without team context skip the fallback (the channel-message Graph
endpoint doesn't apply), matching the user's privacy expectation that
Graph only reaches into channels the app is installed into.

Tests: 3 new cases — happy path end-to-end (direct 403 → Graph success
→ PHOTO event with real bytes), DM without team context (fallback
skipped, attachment dropped), and unit coverage of
_parse_hosted_content_id across the handful of URL shapes.  Full
MSTeams suite stays green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Opt the adapter into the BasePlatformAdapter.edit_message contract
so streaming code paths (StreamConsumer, etc.) can replace an
in-flight placeholder with successive chunks — one visual bubble
per turn instead of a fragmented wall of partial updates.

Implementation:

- _post_activity grew an optional method + message_id pair so the
  same auth / credential / service_url plumbing serves both
  POST /v3/conversations/{chat_id}/activities (send)
  and PUT /v3/conversations/{chat_id}/activities/{message_id} (edit).
- edit_message formats the body through the existing
  markdown_to_teams_html pipeline so edits honour the same HTML
  subset Teams renders on initial sends.  The finalize flag is
  accepted for API parity but no-ops — Teams' update API has no
  separate "done" state.
- Non-retryable shape errors (missing message_id, unsupported HTTP
  method) return a fatal SendResult rather than silently issuing
  the wrong verb.  Transport-level 5xx / 408 / 425 / 429 stay
  retryable, matching send().

Test fakes now implement `session.request(method, url, ...)` so the
single shared dispatch survives both verbs; the narrower `.post()`
shim is kept for existing specs.

Tests: 3 new edit_message cases (PUT URL/body/auth shape,
missing-id guard, 5xx retryable classification).  Full MSTeams
suite at 137 green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The previous attachment handler only downloaded image/* payloads;
everything else — zip, pdf, office docs, plain text — was silently
skipped and the agent replied as if no attachment existed.  A user
dropping a PDF got "You forgot to attach the image".

Generalises _extract_image_attachments into
_extract_media_attachments with a (urls, types, has_image) return:

- file.download.info branch now routes by content.fileType into
  either the image path (png/jpg/jpeg/gif/webp → cache_image_from_bytes,
  MessageType.PHOTO) or the document path (every extension in
  gateway.platforms.base.SUPPORTED_DOCUMENT_TYPES → cache_document_from_bytes
  with the original filename preserved, MessageType.DOCUMENT).
- Classic image/* attachments still flow through the image path
  unchanged.
- Mixed attachments classify the MessageType as PHOTO (vision is the
  more common pipeline) but every file — image or document — lands
  in media_urls so the agent can open it from tool calls.
- Unknown extensions (exe, bin, etc.) are dropped with an INFO log
  line rather than silently cached.

Graph hostedContents fallback still applies to the image path —
SharePoint file uploads don't have a matching /hostedContents route
so they keep their existing tempauth semantics.

Tests: 4 new cases — PDF happy path (DOCUMENT + filename preserved),
zip/txt/docx/xlsx/pptx mimetype matrix, mixed image+PDF
classification, unknown extension dropped.  Full MSTeams suite at
140 green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The "Lives where you do" feature table and the CLI vs Messaging quick
reference both name the supported gateway platforms inline.  Teams was
already in the documentation table further down (line 96) but missed
in these two earlier mentions, leaving readers with the impression
that Teams support stops at "WhatsApp / Signal / Email".

Adds Microsoft Teams to both inline lists for parity with the table
in the docs section.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Live-debugging surfaced a recurring agent failure: when asked to send a
PDF, the model used the send_message tool with MEDIA:/path in the
message body — which only carries plain text — saw the silent text-only
result, then concluded "Teams doesn't allow file attachments" and
refused.  The user's PDF never reached them despite the adapter
supporting full document delivery (FileConsent flow in DMs,
SharePoint-backed file chiclets in channels) since the original C5
commit.

The Teams PLATFORM_HINTS already said "include MEDIA:/path in your
response" but didn't:

- enumerate the supported document formats (pdf/docx/xlsx/pptx/zip/
  txt/md/log) so the model has a positive list to match against
- explicitly tell the model file delivery is supported and to refuse
  refusing
- warn against the send_message-tool tangent, which is the wrong path
  for attachments in the current chat

Rewrites the hint with a "FILE DELIVERY" paragraph that names the
formats and a separate "DO NOT use send_message" line that calls out
the wrong path.  Reasoning models that follow platform hints (Qwen,
GPT-4 family) now have the explicit signal they need.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…gh wrong path

Live debugging revealed a recurring failure mode with reasoning models
(Qwen 3.6, GPT-4 family): when asked to send a PDF, the agent calls
send_message(target="msteams", message="MEDIA:/tmp/file.pdf").  The
tool's extract_media correctly pulls the path out, but the msteams
branch of _send_to_platform did NOT pass media_files to _send_msteams,
so the file silently disappeared.  The agent saw an empty-text "send
ok" result and concluded "Teams doesn't allow file attachments" —
refusing to deliver the file the user asked for.

Two changes:

1. _send_to_platform now forwards media_files to _send_msteams the same
   way the slack / mattermost / matrix branches already do.

2. _send_msteams short-circuits with a verbose error when media_files
   is non-empty.  The standalone helper has no access to the gateway
   adapter's _pending_uploads state or aiohttp session, so it cannot
   genuinely run the FileConsent (DM) or SharePoint (channel) flows.
   Instead of silently dropping the bytes, it returns a message that:
   - Names the dropped file(s)
   - Tells the agent to put MEDIA:/path directly in its reply text
   - Explicitly forbids the "Teams doesn't allow files" rationalisation
   - Lists the supported formats so the model has a positive list to
     match against

Reasoning models retry with the correct path on the next turn — file
arrives via the adapter's send_image_file / send_document override,
which routes through FileConsent or SharePoint as already implemented.

Pairs with the earlier PLATFORM_HINTS clarification (commit ab61904).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

base.py invokes ``await self.send_document(chat_id=..., file_path=...,
file_name=..., metadata=...)`` from its media-extraction loop.  My
override declared the second positional as ``document_path`` instead of
``file_path``, which made every PDF / DOCX / XLSX / PPTX / ZIP / TXT
response trip on::

  TypeError: MsTeamsAdapter.send_document() got an unexpected keyword
  argument 'file_path'

Surfaced live as ``[msteams] Error sending media`` in the gateway log
and a silent agent reply (file never delivered, agent then
hallucinated a Teams limitation).  The send_image_file path used the
right name (``image_path``) and worked, so images shipped while
documents quietly didn't.

- Renames ``document_path`` to ``file_path`` to match the base.
- Accepts ``file_name`` for parity (currently informational — the
  FileConsentCard always shows the on-disk basename).
- Switches the per-method ``metadata=None`` slot to ``**kwargs`` on
  send_document / send_image_file / send_video so any future base
  parameter gets absorbed without re-introducing the same class of
  bug.

New regression test exercises the three overrides with the exact
kwargs base.py uses, so a future name drift fails at unit-test time
instead of in production logs.  Suite at 142 green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>