Optimize thread history fetch for watermark-based adopted context

[Aaronontheweb]

Summary

Follow up the multi-speaker attribution work in #738 by optimizing thread history hydration so Slack and Discord adapters stop fetching full thread history on every authorized inbound message and filtering client-side.

Current Behavior

The adopted-context / authorized-watermark model is correct, but the current implementation does this on each authorized inbound thread message:

1. fetch full thread history from the platform API
2. filter the results locally against the current watermark / cursor
3. build the adopted-context gap from the filtered slice

That preserves correctness, but it can become unnecessarily expensive for long or high-traffic threads.

Desired Outcome

Make thread-history hydration bounded by the existing watermark / cursor semantics instead of always retrieving the full thread.

Scope

• extend the thread history fetcher abstraction to support bounded fetches
• update Slack thread history fetch to request only the relevant window when the platform API supports it cleanly
• update Discord thread history fetch to request only the relevant snowflake range when possible
• preserve the current adopted-context behavior and ordering guarantees from feat: multi-speaker attribution in thread hydration #738
• keep the implementation fail-closed: if a bounded fetch cannot be trusted to be complete, prefer correctness over optimization

Acceptance Criteria

• adapters no longer require full-history fetches for the common non-empty-watermark case
• adopted-context hydration still produces the same message set as the current implementation
• contract/integration tests cover watermark-bounded hydration behavior
• performance improvement is measurable in at least one long-thread scenario

Notes

This should stay separate from #738 itself. The feature behavior and security model are already correct; this issue is about reducing platform/API cost without weakening correctness.