[Feature] Strategy Discovery Phase 3 — description-driven adaptation

Split out of #969, which is closed now that Phase 1 (#978) and Phase 2 (#1007) have landed. That issue said from the start that Phase 3 was out of its scope, and the shape below is the two lines it reserved, expanded against what actually shipped.

What exists now

The Strategy Discovery facade answers what strategies exist and what state they are in, over Alpha Zoo plus the SDM store, with per-regime evidence rows rather than scenario tags:

• list_strategies / query_strategies / get_strategy_evidence — read-only
• refresh_strategy_evidence — rebuilds the disposable evidence cache from local backtest run artifacts, gated by the backtest-diagnose hard gates
• every row carries evidence_stage, provenance (the run directory it was computed from), regime_definition, and a read-time freshness verdict of fresh / aging / stale

The loop that is missing is the one that closes it: a strategy the facade knows about cannot be re-derived for a new universe or regime without the user hand-writing the config.

Proposal

Let strategy-generate take a strategy_id from the facade and produce an adapted SignalEngine from it:

1. Agent resolves strategy_id through get_strategy_evidence
2. Reads the strategy description and the regime definition that evidence was computed under
3. Generates adapted code for the requested universe / date range
4. Backtests it
5. Feeds the resulting run directory back through refresh_strategy_evidence, so the adaptation becomes evidence under its own provenance rather than inheriting the parent's

Step 5 is the part that makes this more than a convenience wrapper: an adapted strategy is a different strategy, and its evidence has to stand on its own run.

Constraints carried over from #969

These are the reasons #894/#896 were rejected, and they apply unchanged:

• No phantom tools. Anything named in a prompt must be registered and callable; guard.py already enforces atomic advertisement and must keep doing so if the tool surface grows.
• No inherited evidence. An adapted strategy must not present the parent's metrics as its own. evidence_stage may not claim a computed result the row's provenance cannot reproduce — enforced in EvidenceRow.__post_init__ as of #978.
• No new seed corpus. Everything reproducible from this repo.

Open questions

1. Does an adapted strategy get a new strategy_id, or a version suffix on the parent's? A suffix keeps lineage queryable; a new id keeps the evidence table honest about them being separate things. Possibly both, with an explicit derived_from column.
2. Should adaptation be refused when the parent's evidence is stale or insufficient, or allowed with the verdict carried into the result? Refusing is consistent with the facade's existing gating; allowing is more useful and arguably still honest as long as the output is labelled.
3. Where does the generated code live — the existing SDM store, or an artifact of the run alone?

No timeline attached. Opening it so the direction is written down rather than living in a closed issue's tail.