perf(sharing): read the earn total from one batched aggregate instead of a per-row query

[argszero]

Summary

Item 2 of rant 2026-09-14T21:15:02 (host report: refreshing #/sharing on dev lands on the login page). Items 1 and 3 shipped in #240 (95d69ba, v0.7.24) and #242 (5d4e6f4); this PR removes the per-row query on the sharing page.

The N+1

sharing.rs::sharing_row fetched each sharing's earnings with

SELECT COALESCE(SUM(pts), 0) FROM transactions WHERE key_id = ?1 AND type = 'earn'

so GET /api/sharings issued N extra statements on top of the list query — each one a prepare plus an index seek, and on the NAS each one touching more pages.

The list and the single-row (PATCH) call sites also had to keep two identical 13-column SELECT lists in sync by hand; the row builder's own doc comment warned that editing only one of them silently misaligns every field. Both problems have the same fix, so this PR makes one change rather than two:

const ROW_SELECT: &str = "SELECT k.id, …, k.created_at, COALESCE(e.earn, 0) \
         FROM keys k \
         LEFT JOIN (SELECT key_id, SUM(pts) AS earn FROM transactions WHERE type = 'earn' \
                    GROUP BY key_id) e ON e.key_id = k.id ";

sharing_row now only reads columns (mirrors the existing admin_models.rs::ROW_SELECT + row_to_json pair), and both call sites use the constant.

Measured on a synthetic 200,000-row table with 8 keys (local SSD, warm cache): eight subqueries 1.54 ms vs one batched aggregate 0.02 ms. The aggregate scans the covering index added in v15 (idx_transactions_key_id_type_pts), so it never touches the table; on the NAS the per-row variant also pays a page read per key, so the gap grows with N.

Why three levels of assertion

Every wrong shape here keeps the same values — that is what made this invisible:

assertion	catches
sharings_earn_is_one_batched_aggregate (values)	type='earn' only, consume-only key is 0, another user's 1000.0 earn neither appears nor leaks into the total, and list/patch agree
the_list_query_aggregates_earn_once_over_a_covering_index (plan)	a correlated subquery (CORRELATED in the plan = the N+1 shape) and a non-covering scan
perf_gate.rs::the_sharing_row_builder_runs_no_sql (shape)	a future query_row inside the row builder — it compiles, every value test still passes, and only the plan gets worse

The gate's positive controls are list/patch in the same file, so it cannot pass by scanning an empty region; perf_gate now covers five route files instead of four.

Related Issue

Tracked as rant 2026-09-14T21:15:02 (no GitHub issue). Item 4 (boot session restore falling back to the login page on a non-401 failure) is still open and will follow as its own PR.

Tests

• cargo test — 256 passed, 0 failed (252 before)
• cargo fmt --check clean
• A/B (fixed tree hash re-verified after each leg):
  • per-row query back inside the row builder → only the new gate red (all value tests stay green — the defect really is invisible to them);
  • aggregate without WHERE type = 'earn' → only the value test red;
  • correlated subquery in the SELECT list → only the plan test red, value test still green.