Pool min_trades across same-parameter rules, with a cross-sectional diversity floor

[eaitbrahim]

The promotion gate judges min_trades = 100 per rule per product (strategy/promotion.py) — so a new asset yields a new rule with its own ~14 trades, never a pooled 114 (the status review's own words). At measured daily rates the floor is unreachable in a human timespan; the hourly profile (#337) makes the sample collectable, and this issue makes the gate able to COUNT it.

Operator-approved 2026-08-17 (the agreement a gate change requires, per CONTRIBUTING's scope rules): change the gate's UNIT OF EVALUATION, not its floors.

Acceptance

• Pooling: when promoting a rule, gather sibling stats — same kind, same params (exact), different product_id, status paper — and compute pooled n / win rate / expectancy / rr honestly from the fields that exist (state the pooling arithmetic in the docstring).
• Gate passes on sample size if EITHER the per-rule stat clears 100 exactly as today (single-product path unchanged, byte-for-byte) OR the pooled sample clears BOTH n_pooled ≥ 100 AND a diversity floor — MIN_POOLED_PRODUCTS (5) distinct products each contributing ≥ MIN_TRADES_PER_PRODUCT_POOLED (10) trades. Both constants named, docstring'd, with the correlation rationale: crypto assets correlate, so pooled-but-correlated samples overstate power; the diversity floor is the honest discount.
• min_trades = 100 itself is untouched. The recorded discipline stands: the win-rate axis was relaxed ALONE once; axes move only with their own justification.
• Quality floors (expectancy / rr / win rate) judged on the POOLED stats when the pooled path is used; on the rule's own stats otherwise.
• keel rules promote reports BOTH readings (per-rule n, pooled n, diversity census); failure reasons name their path ("pooled n 84 < 100 across 7 products", "pooled diversity 3 products < required 5").
• Default behavior unchanged for promotions that already pass on a single product.