Per-device show/hide of users in the Chores widget

[mrramam]

A display in one room often only needs some of the users. The gear on the chore widget now hides users on that display alone.

Ordering stays global — users.sort_order is admin-controlled and untouched. Only visibility is per device, stored as hidden ids in choreWidgetSettings.hiddenUserIds, so there's no migration.

It stores who is hidden rather than who is shown, deliberately: storing the visible set would make a user added later invisible on every existing display until someone opted them in on each one.

Hiding everyone renders an explanatory panel rather than an empty widget — on a wall display a blank widget reads as a crash. Stale ids are pruned against the live user list, so a deleted user can't break a display.

Filtering and toggling logic is in utils/choreUserVisibility.js with tests. features.md updated.

Tested on a real instance, both themes and narrow widths. Node 20: client 144, server 190, check:i18n 715/715, build clean.

[jherforth]

Merged. Given how much interlocking logic sits in the chore widget, I traced this one carefully — and it lands in the right place.

The filter is a derived visibleUsers used only for rendering columns; the users state itself is untouched. That matters more than it looks, because the daily-bonus check, the all-chores-done celebration, and the transfer target list all read users and would have changed behaviour silently if the filter had narrowed the state instead.

I did stop at - users.filter(user => user.id !== 0) becoming + visibleUsers.map(...), since filterVisibleUsers doesn't exclude the bonus pseudo-user. It's fine: setUsers already strips id 0 at fetch time and that's the only write path, so the render-site filter was redundant. Worth stating explicitly since the safety depends on a line 700 lines away.

Storing hidden rather than visible ids is the right call, and the reasoning generalises — a later-added user appearing everywhere by default beats being invisible until opted in on every display.

Probed the util directly beyond the unit tests: string ids match after a JSON round-trip, a deleted user's stale id hides nobody, prune drops stale + dedupes + rejects non-numeric, and nothing mutates its input. The empty-state panel is good wall-display thinking.

One interaction this creates, worth a thought rather than a change: the all-chores-done confetti still fires for hidden users, because the celebration reads the full user set. A display that hides Noah will still celebrate when Noah finishes. The confetti is wordless so it's not incoherent, and household-wide joy is defensible — but it's a new question this PR opens and I didn't want to decide it unilaterally.

Verified merged with main, not the branch alone: 146 client, 208 server unchanged, i18n 727/727, build clean, no conflicts.