SPA: Expenses filters by a single month, where every sibling screen filters by a date range

[mforce]

Found while implementing #653.

ExpensesPage.tsx:486 filters with one <input type="month">:

<input type="month" value={month} max={today.slice(0, 7)} …

Every sibling list screen — Feed, Water, History, Reports — filters with a from/to date pair. #653 wrapped the month picker in the new bounded .toolbar alongside the others, which is the right minimal move for that slice, but it leaves Expenses the only screen where the question you can ask of the data has a different shape from everywhere else.

(The other two type="date" inputs on that page, at lines 564 and 644, are entry-form fields for recording an expense, not filters. They are not part of this.)

The actual question

Is the month granularity deliberate? There is a real argument for it — expenses are reconciled monthly, invoices and utility bills land monthly, and a month picker is one control instead of two. If so, this issue closes as won't-fix with that reasoning recorded, and the inconsistency becomes a documented choice rather than an oversight.

If it is not deliberate, the fix is a from/to pair matching the siblings, and:

• Reports summarises expenses over its own from/to range, so the two screens currently answer different questions about the same data — a user reconciling one against the other has to translate between them.
• The API side needs checking: does the expenses list endpoint take a range, or only a month?
• docs/images/reports.png shows the money section aggregating expenses over a date range, which is the shape the list screen does not offer.

Either outcome is fine; what is not fine is that nobody has decided. Filed so the decision gets made and recorded rather than inherited.

Related: #653.

[mforce]

Decision: the month granularity is not deliberate — converting to a from/to pair

This issue asked for a decision to be made and recorded rather than inherited. Owner decided 2026-09-03: convert to a from/to pair matching Feed, Water, History and Reports.

The API question this issue raises is already answered in the shipped code. ExpenseEndpoints.cs:122-134 takes from/to, and IExpenseRepository.ListAsync/SumAsync both filter on them. ExpensesPage.tsx:145 (monthRange) already converts the chosen month into exactly that pair before calling the API. So the month picker is a UI-side narrowing of a range the backend has supported all along — SPA-only change, and monthRange is deleted rather than rewired.

Two consequences worth flagging before the PR, because neither is obvious from the issue:

The default window. Expenses opens on the current month today, and its period total is a money figure whose meaning comes from that window. Opening blank like the siblings would silently change the default from "this month's spend" to "every expense ever recorded, and a total to match". So the new pair defaults to the current farm month — a deliberate divergence from the siblings' blank default, recorded rather than discovered.

The strings are callers. monthTotalLabel ("Month total: {{amount}}") is renamed to periodTotalLabel — a key named for a month holding a string describing a range is the same wrong-statement class, one layer down. monthLabel is retired, and noExpensesMessage ("No expenses for this month.") stops being true for a range and gains a filtered-empty sibling. All three locales, same PR.

Also being retired with it: ExpensesPage.tsx:492 is the last input[type="month"] in web/src. The CSS rule at styles.css:1083-1085 and the guard arm at styles.toolbar.test.ts:32 that pin its width go with it, rather than being left as a rule with zero call sites and a test asserting it.

Design: docs/designs/666-667-spa-date-range-filters.md. Shipping together with #666 and a Stock fix in one PR.