fix(ui): let the dashboard trend's green bar be named the series it draws

[argszero]

Summary

On the dashboard card "近 14 天消耗与收益" / "Consumption & earnings, last 14 days", the green bar is bound to the backend income series — the direction whitelist earn + topup + gift (TX_INCOME_TYPES, src/routes/wallet.rs) — but it is labelled dash.trend.earn = 「共享收益」/ "Sharing earnings".

On the same screen, the dash.earnings stat card uses that same name for a different fact: true earn only (month_earn, SQL type = 'earn'). So one screen carries two facts under one name. A user who has topped up sees the green bar at 5000 while the card beside it reads 0.

The transactions page already calls this series 「收入」/ "Income" (tx.trend.metric.income), and its own subtitle for the total says 「共享分成等收益」 — it states the total is a superset of earnings.

Birth order confirms this is drift, not a tradeoff: 「收入」 dates from #133; #155 gave the same series a narrower name 22 PRs later, in a commit whose comment claimed the same scope as the transactions page.

The fix is the name, not the data. Key dash.trend.earn → dash.trend.income, values 「收入」/ "Income". The bar still draws income; no series, query or number changed. All three carriers of this series in the card (legend in index.html, tooltip in renderDashTrend, transactions-page legend) now share one key, whose pack values are identical on both sides.

The consumption label is deliberately left alone — it already agrees.

Related Issue

None: no open issue matches this, and it is a small self-contained fix.

Changes

• ui/js/i18n.js — key renamed in both packs (ZH 「共享收益」→「收入」, EN "Sharing earnings"→"Income"); key count unchanged.
• ui/index.html — legend data-i18n + its static fallback, and the i18n.js/app.js cache-bust token bumped.
• ui/js/app.js — tooltip T(...) key; comment corrected to state what the bar actually draws.
• ui/README.md — contract line: one series, one word (with an honest scope note).
• src/state_gate.rs — new gate the_dashboard_trend_names_its_series_the_way_the_transactions_trend_names_it: four derived rules + roster positive control + four mutation teeth + scanner self-test.
• No change to config or data structures.

Tests

• cargo test all pass — 396 passed / 0 failed (baseline 392; the gate adds 4).
• cargo fmt --check passes (rc 0).
• cargo clippy --all-targets -- -D warnings passes (rc 0).
• New tests added: the gate above.

A/B teeth proof — the gate was measured against the reverted fix in the same clone (git apply -R of the UI diff, then restored):

the_dashboard_trend_names_its_series_the_way_the_transactions_trend_names_it ... FAILED
  r1=true r2=false r3=false r4=true
  legend_key=Some("dash.trend.earn") tooltip_key=Some("dash.trend.earn")
  tx_key=Some("tx.trend.metric.income") rhs=Some("b.income || 0")

Exactly the two naming rules fail, while r1 (the bar reads income) and r4 (the earn-only card still supplies month_earn) stay true — which is what a naming defect should look like: the data was never wrong, only its name.

Checklist

• Branch naming follows the convention (fix/)
• Commit message uses Conventional Commits
• Single responsibility, minimal change