…lee-level test

Round-3 review findings on PR #39:

- `docs/channels/msteams.md` "Set to \`false\` explicitly on any
  deployment that overrides this default and wants to opt out." leaked the
  existence of a fork override to the upstream docs mirror while sitting
  next to "Default: false.". Drop the trailer; the default sentence is
  enough for upstream readers, and the fork `CHANGELOG.md` still
  documents the fork override + opt-out.
- `extensions/msteams/src/monitor-handler/inbound-media.test.ts:231`
  test title said "(upstream default)", but the assertion is at the
  callee boundary and stays valid regardless of the caller's default. The
  message handler applies the resolver upstream, so this test proves the
  callee contract, not the caller default. Retitle + rewrite the leading
  comment to describe the contract, not the (now-misleading) upstream
  behavior.

Round-3 finding #3 (PLAUSIBLE, not filed): no message-handler-level
end-to-end test that exercises the fork default. Accepted as-is —
resolver unit tests + explicit callee-level tests + comment coverage give
enough confidence for a 1-line default flip. Full message-handler test
scaffolding is heavy and out of scope for this PR.

)

* fix(msteams): default alwaysFetchGraphMessage=true on the Boon fork

Every Teams tenant in the Boon fleet observed the ENG-14349 Bot Framework
stub-stripping regression - inbound activities arrive without the
`<attachment id=...>` HTML stub and without `reference`-typed entries
even with RSC consent granted, so attachments silently vanish unless the
Graph re-fetch path fires.

Upstream 6.11 already ships the fix as opt-in config
`channels.msteams.alwaysFetchGraphMessage` (default off, kept off upstream
so tenants where Bot Framework delivers the stub correctly don't pay
per-message Graph latency). The Boon fleet does not have such tenants -
every Teams host was previously relying on a host-local msteams SP-PATCH
baked in via gandalf-manager `scripts/fleet-msteams5.22-bump.sh`.

Flip the fork default via a small resolver so an explicit `false` still
opts out per host, and the change is unit-testable without wiring through
the full message-handler.

Version bump: 2026.6.11-boon.1 -> 2026.6.11-boon.2.

* fix(msteams): align config docs + shrinkwrap with fork default flip

Round-1 review findings on PR #39:

- `npm-shrinkwrap.json` still pinned `2026.6.11-boon.1`; regen via
  `scripts/generate-npm-shrinkwrap.mjs` so release-check version parity
  (`scripts/check-openclaw-package-tarball.mjs:243`) passes.
- Config-contract docs at `src/config/types.msteams.ts:164` and
  `src/config/zod-schema.providers-core.ts:1651` still asserted
  "Default false." — now note upstream=false / fork=true so the schema/type
  peer stays aligned with the runtime resolver, per root `CLAUDE.md`
  "Config contract: exported types, schema/help, metadata, baselines, docs
  aligned."

* docs(msteams): document alwaysFetchGraphMessage + sync inbound-media JSDoc

Round-2 review findings on PR #39:

- `extensions/msteams/src/monitor-handler/inbound-media.ts:37` — the
  sibling JSDoc on `resolveMSTeamsInboundMedia`'s param still said
  "Default false (upstream behavior)." and is what editors surface at the
  message-handler call site. Note that the caller resolves the fork default
  before calling in.
- `docs/channels/msteams.md` — `alwaysFetchGraphMessage` was never
  listed in the user-facing Configuration section even upstream; add it so
  the flag is discoverable and the CHANGELOG's opt-out (`false`) is
  findable via docs. Doc source publishes to the openclaw/docs upstream
  mirror, so the entry stays upstream-neutral and describes upstream
  behavior; the fork-specific default is called out only in the fork
  `CHANGELOG.md` and in the internal-facing schema/type JSDoc.

* docs+test(msteams): tighten alwaysFetchGraphMessage doc + retitle callee-level test

Round-3 review findings on PR #39:

- `docs/channels/msteams.md` "Set to \`false\` explicitly on any
  deployment that overrides this default and wants to opt out." leaked the
  existence of a fork override to the upstream docs mirror while sitting
  next to "Default: false.". Drop the trailer; the default sentence is
  enough for upstream readers, and the fork `CHANGELOG.md` still
  documents the fork override + opt-out.
- `extensions/msteams/src/monitor-handler/inbound-media.test.ts:231`
  test title said "(upstream default)", but the assertion is at the
  callee boundary and stays valid regardless of the caller's default. The
  message handler applies the resolver upstream, so this test proves the
  callee contract, not the caller default. Retitle + rewrite the leading
  comment to describe the contract, not the (now-misleading) upstream
  behavior.

Round-3 finding #3 (PLAUSIBLE, not filed): no message-handler-level
end-to-end test that exercises the fork default. Accepted as-is —
resolver unit tests + explicit callee-level tests + comment coverage give
enough confidence for a 1-line default flip. Full message-handler test
scaffolding is heavy and out of scope for this PR.

* fix(msteams): drop extensions/ path from core config JSDoc

CI `checks-fast-contracts-channels-a` failure: the round-1 doc updates
inserted the plugin-private path
`extensions/msteams/src/monitor-handler/graph-fallback-default.ts` into
core `src/config/types.msteams.ts` and `src/config/zod-schema.providers-core.ts`
JSDoc, which triggered
`src/channels/plugins/contracts/channel-import-guardrails.test.ts`
("keeps core production files off plugin-private src imports").

Reword the doc so it names the fork consume-site by plugin
(`@openclaw/msteams`) and describes the runtime seam (resolver applied
before `resolveMSTeamsInboundMedia`), rather than pointing at a
plugin-private source path. Verified locally:
- `channel-import-guardrails.test.ts`: 148 tests passing.
- `graph-fallback-default.test.ts` + `inbound-media.test.ts`: 16 tests
  passing.