feat(intel): add get_trend_signals — surge/decline detection against rolling baselines

Deferred from #5694 (proposed scope item 4, deliberately not in that issue's acceptance criteria).

#5694 asked for four retrieval capabilities and listed acceptance criteria for three. #5737 shipped those three — `search_intel_history`, `get_intel_timeline`, `get_similar_events`. This is the fourth, filed so it does not vanish when #5694 closes.

## What it is

*"What has surged vs its baseline this week?"* — trend detection over the accumulated history rather than point-in-time retrieval. Unlike its three siblings this one **computes** rather than fetches: it needs rolling baselines per domain/country and a defensible definition of "surge".

## Why it was deferred, not forgotten

The three shipped tools are pure reads over an existing index. Trend detection needs design decisions the store's first data cannot inform yet:

- Baseline window and update cadence (rolling N-day? same-period-last-year? both?).
- What is counted — record volume, severity-weighted volume, or embedding-space drift?
- The store starts empty at activation, so **any baseline is meaningless until enough history accumulates**. Shipping this before the store has depth would produce confident nonsense.

That last point is the real blocker: this is worth building after the store has weeks of data, not before.

## Prerequisite

Meaningful history accumulation, which requires the Railway env activation described in #5737 and enough elapsed time. Revisit once the three collectors have been writing for a few weeks.

## Acceptance criteria

- [ ] A documented baseline definition, with the empty/thin-history behavior stated (must degrade honestly, not report a surge from three records).
- [ ] Exposed via MCP + REST as a Pro-gated route, matching its three siblings' registry wiring.
- [ ] Tests covering surge, decline, insufficient-baseline, and empty-store cases.

Revisit this after the three collectors have accumulated meaningful history through the Railway activation in #5737. Review search_intel_history, get_intel_timeline, and get_similar_events, including their MCP and REST registry wiring, then define the baseline and thin-history behavior. Done means documented surge and decline rules plus tests for surge, decline, insufficient-baseline, and empty-store cases.

Written by the indexing model from the issue text.