Title: fix(msteams): paginate thread replies and keep recent context

Summary

• Problem: Teams thread context enrichment only used the first Graph replies page, so long threads could skew toward the oldest replies.
• Why it matters: the bot could miss the newest thread context, which is usually the most relevant context for a channel-thread reply.
• What changed: fetchThreadReplies now follows @odata.nextLink under a hard page cap and returns the most recent bounded reply window instead of only the first page.
• What did NOT change (scope boundary): no live-tenant Graph validation, no changes to higher-level message-handler behavior, and no prompt-formatting changes beyond the selected reply window.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: the Teams thread helper fetched only the initial Graph replies page even when Graph exposed additional pages via @odata.nextLink.
• Missing detection / guardrail: there was no unit coverage for paginated reply retrieval or for preferring the newest bounded reply window.
• Contributing context (if known): the Graph replies endpoint is oldest-first and does not support $orderby, so a single-page implementation silently favors stale context on long threads.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/msteams/src/graph-thread.test.ts
• Scenario the test should lock in: when Graph returns multiple reply pages for a channel thread, the helper follows pagination and keeps the most recent bounded reply window rather than only the first page.
• Why this is the smallest reliable guardrail: the bug is isolated to the Graph reply helper and can be reproduced deterministically with mocked paginated Graph responses.
• Existing test that already covers this (if any): none before this change.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• Long Teams channel threads can now contribute newer reply context to the bot instead of only the oldest reply page.
• Behavior stays best-effort: if Graph pagination or fetches fail, the surrounding handler still degrades gracefully as before.

Diagram (if applicable)

Before:
[long Teams thread] -> [fetch first replies page only] -> [oldest replies injected] -> [bot may miss latest context]

After:
[long Teams thread] -> [follow paginated replies with hard cap] -> [keep most recent bounded window] -> [bot sees newer thread context]

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (Yes)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:
  • Risk: this can issue additional Graph requests for long threads.
  • Mitigation: pagination is capped at 10 pages and the helper still returns only the requested bounded reply window.

Repro + Verification

Environment

• OS: macOS
• Runtime/container: repo-local Node via pnpm openclaw
• Model/provider: N/A
• Integration/channel (if any): MSTeams Graph helper unit tests
• Relevant config (redacted): N/A

Steps

1. Mock the first Graph replies page with reply-1, reply-2, and an @odata.nextLink.
2. Mock the second page with reply-3, reply-4.
3. Call fetchThreadReplies(..., limit=2).

Expected

• The helper should follow the next link and return the newest bounded window: reply-3, reply-4.

Actual

• Before the fix, the helper would only use the first page and return reply-1, reply-2, dropping the newer page entirely.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: targeted unit run for extensions/msteams/src/graph-thread.test.ts; paginated reply path; hard page-cap path; existing thread-helper tests remained green.
• Edge cases checked: missing value, min/max limit clamping, bounded pagination cap.
• What you did not verify: live Microsoft Graph behavior against a real Teams tenant or real long thread pagination ordering/latency.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk: Microsoft Graph pagination behavior for long Teams threads has not been validated against a real tenant in this change.
  • Mitigation: the PR makes the assumption explicit, keeps the change local to the helper, and adds deterministic regression tests around the intended pagination behavior.
• Risk: extra Graph fetches could increase latency on large threads.
  • Mitigation: page following is hard-capped and still returns only a bounded recent window.