Move typingIndicator field to MSTeams config schema

The added typingIndicator property is currently wired into DiscordAccountSchema, but the new behavior reads channels.msteams.typingIndicator and MSTeamsConfigSchema is strict. That means users who set channels.msteams.typingIndicator will get a validation error for an unknown key, so the new Teams config knob cannot actually be used, while an unrelated Discord account key is now accepted but ignored.

Useful? React with 👍 / 👎.

typingIndicator added to the wrong Zod schema

This property was added to DiscordAccountSchema (line 479), but the feature is implemented in the MS Teams extension and should be in MSTeamsConfigSchema (around line 1536).

Because MSTeamsConfigSchema uses .strict() (line 1560), any user who sets channels.msteams.typingIndicator: false in their config will receive a Zod validation error like "Unrecognized key(s) in object: 'typingIndicator'" — completely preventing the config knob from working.

The fix is to remove the field from DiscordAccountSchema and add it to MSTeamsConfigSchema instead, adjacent to the existing blockStreaming field:

// In MSTeamsConfigSchema (~line 1536):
    chunkMode: z.enum(["length", "newline"]).optional(),
    typingIndicator: z.boolean().optional(),
    blockStreaming: z.boolean().optional(),

And remove it from DiscordAccountSchema:

// In DiscordAccountSchema (~line 497):
    chunkMode: z.enum(["length", "newline"]).optional(),
    blockStreaming: z.boolean().optional(),

Note: pnpm config:docs:gen should also be re-run to keep the baseline artifact in sync (per repo CLAUDE.md guidelines).

This is a comment left during a code review.
Path: src/config/zod-schema.providers-core.ts
Line: 498

Comment:
**`typingIndicator` added to the wrong Zod schema**

This property was added to `DiscordAccountSchema` (line 479), but the feature is implemented in the MS Teams extension and should be in `MSTeamsConfigSchema` (around line 1536).

Because `MSTeamsConfigSchema` uses `.strict()` (line 1560), any user who sets `channels.msteams.typingIndicator: false` in their config will receive a Zod validation error like `"Unrecognized key(s) in object: 'typingIndicator'"` — completely preventing the config knob from working.

The fix is to remove the field from `DiscordAccountSchema` and add it to `MSTeamsConfigSchema` instead, adjacent to the existing `blockStreaming` field:

```
// In MSTeamsConfigSchema (~line 1536):
    chunkMode: z.enum(["length", "newline"]).optional(),
    typingIndicator: z.boolean().optional(),
    blockStreaming: z.boolean().optional(),
```

And remove it from `DiscordAccountSchema`:
```
// In DiscordAccountSchema (~line 497):
    chunkMode: z.enum(["length", "newline"]).optional(),
    blockStreaming: z.boolean().optional(),
```

Note: `pnpm config:docs:gen` should also be re-run to keep the baseline artifact in sync (per repo CLAUDE.md guidelines).

How can I resolve this? If you propose a fix, please make it concise.

typingIndicator appears to be an MS Teams config flag, but it’s being added to DiscordAccountSchema here. Since MSTeamsConfigSchema is .strict() and currently does not include typingIndicator, setting channels.msteams.typingIndicator would still fail config validation (and Discord would gain an unused field). Move this field into MSTeamsConfigSchema (and remove it from Discord), then regenerate any derived config metadata/schema artifacts as needed.

The docstring says “Default: true for groups/channels; DMs use informative stream status”, but in the runtime implementation native typing is only supported for personal and groupchat conversation types (not channel). Consider rewording to “group chats” (and clarify that 1:1 chats suppress native typing when the informative status stream is used).

This test asserts native typing behavior for conversationType="channel", but the dispatcher only supports typing activities for personal and groupchat conversations (channel uses a no-op typing sender). Using groupchat here (and in the opt-out test) would better match real typing-supported scenarios and reduce the risk of the test passing even if typing is never actually emitted for supported conversation types.

Fallback to native typing when informative update fails

onReplyStart now suppresses typingCallbacks.onReplyStart() for every personal chat based only on hasStream(), but sendInformativeUpdate() swallows send failures internally (onError + continue). In DMs where the streaminfo typing activity is rejected or fails transiently, this branch skips both informative status and native typing, which is a regression from previous behavior where native typing still ran. Please gate the skip on a successful informative send (or otherwise keep native typing as a fallback) so DM users still get typing feedback when stream initialization fails.

Useful? React with 👍 / 👎.

Match HTML attachments by prefix instead of exact MIME

extractTextFromHtmlAttachments only accepts attachment.contentType === "text/html", so attachments reported as text/html; charset=utf-8 are skipped and their message text is never extracted. In those cases rawText often stays empty and the handler falls back to attachment placeholders, which can make normal text messages look like file-only messages and bypass expected text processing.

Useful? React with 👍 / 👎.

Parse the content.content HTML payload variant

The new fallback extractor only checks attachment.content.text and attachment.content.body, but Teams attachments in this codebase also support attachment.content.content (see the shared HTML extraction utility). When that variant arrives, this branch returns an empty string and the inbound message text is lost even though valid HTML content is present.

Useful? React with 👍 / 👎.