feat(analytics): planet insights aggregate v2 (amounts, recipe mixes, user thresholds) and the plan suggestions preference

[jplacht]

What and why

Planet insights are too thin to drive suggestions in the building and recipe pickers. Hard cutoffs drop most buildings and recipes. There are no amounts and no recipe combinations, and the counts are of plans rather than players. This adds v2 data (per-building amounts, recipe mixes, expert counts) with player-based thresholds next to the unchanged v1 keys, plus a "Plan suggestions" preference for the frontend work in insights-01b and insights-02.

Changes

• The aggregator adds v2 buildings (amounts, recipes, top 3 recipe mixes) and experts, collected in the same pass as v1. The v1 keys are unchanged, checked by a snapshot test against main's output.
• Player-based thresholds:
  • A planet needs ≥ 15 plans and ≥ 10 users.
  • Buildings, recipes and mixes need ≥ 5 % and ≥ 10 users.
  • Medians round half up.
• total_users on AnalyticsPlanAggregate (migration 0008) and in the response. below_threshold now sends insights_data: null instead of aggregated_data, which the frontend already accepts.
• New user preference planSuggestions (default true).
• seed_perf adds 12 insights users on KW-688c, so the e2e stack has one planet that passes every threshold.

Expert type in v2 is the value stored in plans (Chemistry, Resource_Extraction).

How it was verified

• QA: PASS after 2 rounds (round 1 full, round 2 scoped to a seed fix).
• ruff check, ruff format --check, ty check, pytest (809 passed).
• /sync-api against today's frontend: additive changes only, no breaks.
• e2e stack:
  • KW-688c returns total_users: 12 with FRM in two mixes.
  • A below-threshold planet returns insights_data: null.
  • The plan editor's insights box still renders.
  • UI audit of the plan page: no regressions versus the baseline.

Deploy

Can deploy alone; it is backward compatible. After deploy, run "Run aggregator" once in the admin (Plan Aggregates) so existing rows get the v2 keys. Before shipping, check on prod data how many planets still pass with ≥ 10 players.

🤖 Generated with Claude Code

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 33 complexity · 0 duplication

Metric	Results
Complexity	33
Duplication	0

View in Codacy

🟢 Coverage 98.97% diff coverage · +0.12% coverage variation

Metric	Results
Coverage variation	✅ +0.12% coverage variation (-1.00%)
Diff coverage	✅ 98.97% diff coverage

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (7dd03bf)	4791	4579	95.58%
Head commit (ebb2fda)	4883 (+92)	4673 (+94)	95.70% (+0.12%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#70)	97	96	98.97%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}