fix(wallet): fill the dashboard's 7-day series window so the sparkline's x axis is time

[argszero]

Summary

GET /api/dashboard's series is a sparse day-bucket list: GROUP BY date(time) emits a row only for days that actually have transactions.
ui/js/app.js (renderMonthChanges) hands that list straight to
sparkline(), which places point i at an index-based x
(pad + i*(w - 2*pad)/(len - 1)) instead of at its date. Days without
transactions were therefore collapsed rather than shown as zero.

Measured with jsdom (the real ui/index.html plus the four real scripts, only
fetch stubbed), driving the real card:

series fed to the card	stroke path	line segments
1 active day — what the handler returns today	M60.0 2.0	0
the same week, window-filled	M2.0 32.0 L21.3 32.0 ... L118.0 2.0	6
2 active days, first and last	M2.0 2.0 L118.0 32.0	1

With a single active day the fill path has zero area and the stroke path is a
lone M command (per the SVG spec a subpath holding only a moveto is not
stroked), so there is no line at all while the number above it still
renders. With two active days the two points are stretched across the full
width, drawing a week-long trend out of a one-day spike.

The convention this breaks is written down four times in this tree, each time
with its reason:

• src/routes/ops.rs::runtime fills hours 0..23 — 「GROUP BY 会省略无调用的
  小时，若不补零前端柱状图会整体左移」;
• ui/js/app.js::dashTrendDays fills its day buckets — 「后端 GROUP BY 只返回
  『有交易』的日桶 … 缺行会让柱子左右移位」 (feat(ui): redesign dashboard, model market and sharing views (PR 4/6) #155/feat(ui): redesign wallet/transactions views on the landed component layer #156);
• ui/js/app.js::txTrendDays repeats it for the transactions chart;
• the guest branch of this very function always hands over 7 points.

The sparse series was wired up in f525242 (#79); every sibling was filled
afterwards. This is the one consumer that was left out — an omission, not a
choice. sparkline() has exactly two call sites (the guest branch's fixed
7-point array and this one), and the tree's three time-bucketed aggregations
(ops.rs::runtime, this endpoint, transactions_trend) now all fill their
window.

Related Issue

None (no issue exists for this; none was fabricated).

Changes

• src/routes/wallet.rs — series now builds its window with a
  recursive CTE (today plus the previous 6 days, UTC) and a LEFT JOIN
  whose ON clause carries the user filter, so every day of the window
  gets exactly one row and days with no transactions get 0.
  The user filter has to stay in the JOIN condition: in WHERE it
  would discard precisely the empty days this change exists to add
  (verified by mutation — see below).
• src/routes/wallet.rs — the endpoint's doc comment now states the fill
  (the doc already contrasted the two windows after C2049).
• src/routes/wallet.rs — the old assertion !v["series"].is_empty()
  is trivially true once the window is filled, so it is rewritten into the
  shape assertion it meant (7 rows, ascending, ending today).
• New tests dashboard_series_is_a_zero_filled_seven_day_window and
  dashboard_series_zero_fills_inside_the_user_and_the_window.

Not touched, on purpose: sparkline()'s per-point title structure (that
needs a browser-capable probe, recorded separately), the guest branch's dead
code, and the front-end. Zero-filling on the client was rejected on purpose:
it would re-derive a window the server already owns — a second copy of
date('now','-6 days'), which is exactly what C2094 judged a defect when the
week bucket was defined twice.

The window semantics are unchanged: still date(time) day keys, still
anchored on date('now', '-6 days'), still UTC. month / net (the
C2049 windows) are untouched.

Tests

• cargo test — 222 passed (was 220).
• cargo fmt --check — clean.
• cargo clippy --all-targets -- -D warnings — clean.
• dashboard_series_is_a_zero_filled_seven_day_window — asserts 7 rows in
  ascending order whose date set equals the window computed from
  chrono::Utc::now() (an authority independent of the CTE under
  test).
• dashboard_series_zero_fills_inside_the_user_and_the_window — asserts
  the per-day values, each compared against a plain per-day SUM for the
  same user; another user's row inside the window and this user's row
  outside it must not appear; then a positive control writes a new
  transaction onto a day that was zero-filled and re-reads the endpoint, so
  the fill cannot be hiding data.
• A/B — each mutation applied alone, reverted with the file's md5
  restored (baseline e6251ed2..., unmutated tree
  222 passed / 0 failed):
  - M1 the pre-change sparse query reddens 3:
  dashboard_series_is_a_zero_filled_seven_day_window,
  dashboard_series_zero_fills_inside_the_user_and_the_window,
  wallet_summary_and_dashboard — i.e. the new tests reject the
  pre-change tree.
  - M2 window off by one (-5 days) reddens 2 — a different set — and
  includes the shape test but not the value test.
  - M3 user filter moved into WHERE reddens the same 3 as M1 (moving
  it back into the join is the whole point of the LEFT JOIN).
  - M4 joining a datetime column against a date key reddens exactly 1:
  the value test, which is what makes it the guard for per-day values.
• End-to-end: jsdom running the real ui/index.html with the unmodified
  api.js / data.js / i18n.js / app.js, fed the exact
  series the patched handler produces (captured from the router test): 7
  points, 6 line segments, 7 tooltips — against 1 point, 0 segments for the
  pre-change shape.

Checklist

• Branch name follows the convention (fix/).
• Commit message uses Conventional Commits (fix(wallet): ...).
• Single responsibility, minimal change.
• No config / schema change, so no example-file sync is needed.
• No ui/ or i18n key change, so the i18n gates are unaffected.