[Feature] System-Account (non-family account) für Wall Display

[trinitrion]

Problem

A wall display currently has to run under a regular user account, which means it's treated as a household member, inheriting that account's permissions and showing up in the Overview, member lists, etc. The current workaround is creating a dedicated "Display" account, but it still counts as a family member and clutters member-facing views.

Request

Add a dedicated system/service account type for shared displays: authenticated like a normal account (so it can be scoped/permissioned), but excluded from family-member views (Overview, member lists, birthdays, etc.) and not counted as a household member.

[ulsklyc]

Good framing - and worth saying up front that the precedent for this already exists in the codebase, which changes what the work actually is.

users.access_scope is already a real axis: auth.js resolves every account to family or split_guest, and a split guest is exactly what you are describing - an authenticated account that is deliberately not a household member. It is how somebody outside the family can settle a shared expense without appearing in the family views. What makes it narrow today is that membership in that scope is derived from one table (split_expense_guest_users) rather than being a property you can assign.

So this is not "add a new account type from scratch". It is "generalise an axis that already carries one non-member scope". That is a much better starting position, but it also means the interesting question is not the type - it is the exclusion list, which is where this kind of feature usually goes wrong.

A display account has to disappear from: the Overview member cards, member pickers (task assignee, event attendee, budget split participants, medication owner), the birthday list and the birthday widget, family-role-based permission rules, and the CSV/health exports that group by person. Each of those reads the member list through its own query today. A scope flag that is only honoured in three of them is worse than none, because the operator believes the display is hidden and it is showing up in the fourth.

The other half is what such an account is for: it needs to read the dashboard and nothing else, ideally with no session that can navigate elsewhere and no password worth stealing off a wall-mounted tablet. Permissions can already express "read-only, most modules none" per role, so a good chunk of that is configuration rather than new code.

Two things I would want settled before any of this is designed, since they change the shape:

1. Should a display account be able to act at all - tick a task off the wall dashboard, say - or is it strictly read-only? Wall mode is currently interactive, and "cannot be a member" and "can complete a chore" are not the same restriction.
2. Should it authenticate like a normal account (username/password, sessions, 2FA prompts on a tablet nobody logs out of) or be closer to a long-lived device token that the operator provisions once?

@ulsklyc has the call on both. I have not scoped this as accepted - just mapping what is already there so the discussion is not starting from zero.

Related: #915 (make wall mode customizable) overlaps here, since both end up asking what a wall display is allowed to be.