feat: exclude guest accounts from the employee directory

Guest accounts — users created by the Guests app — are external people invited
to collaborate on files. They have no entitlement and take no leave, but the app
treated every account as staff, so each guest sat in the balances report and the
who's-off calendar forever with an empty allowance and nothing to show.

Four services each walked IUserManager with their own copy of that loop, so a
rule about who is *not* an employee had to be repeated four times to hold — and
would silently not hold wherever it was forgotten. EmployeeDirectory is now the
one place that answers "who are the employees", and ReportService,
EntitlementService, CoverageService and ManagerResolver all ask it.

Detection reads the user backend: a guest lives in the Guests app's own backend,
which is what OCA\Guests\GuestManager::isGuest() checks too. Read that way the
app needs no dependency on the Guests app — where it is absent or disabled no
account has that backend and the rule is simply never true, so instances without
guests are unaffected.

Enforced, not merely hidden. Filtering only the lists would leave the rule one
crafted request away from being bypassed, so the API rejects recording leave for
a guest (including by HR, who may otherwise record for anyone), nominating one as
a replacement, and setting one's entitlement. Guests also cannot be resolved as a
line manager: that is more than tidiness, because a request routed to a guest
approver could never be approved.

The people pickers move off core's autocomplete to a new /api/employees/search,
because only the server can tell a guest from a colleague — a client-side filter
would be no filter at all. It wraps the same collaborator search core uses, so
the admin's user-enumeration settings keep applying exactly as before; guests are
removed from whatever that search returns.

Existing records for someone who later becomes a guest are left untouched in the
database; they simply stop being listed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: Frank Karlitschek

SPECIFICATION.md

@@ -51,7 +51,7 @@ There are four effective roles. A single user may hold several simultaneously
 
 | Role | How assigned | Capabilities |
 |------|-------------|--------------|
-| **Employee** | Every logged-in user | Create/edit/cancel own requests, view own balance, view own history, see team who's-off calendar. |
+| **Employee** | Every logged-in user **except guest accounts** (§2.2) | Create/edit/cancel own requests, view own balance, view own history, see team who's-off calendar. |
 | **Line manager** | Derived from the LDAP `manager` attribute (see §2.1) — a user is a manager of everyone whose `manager` attribute points to them | Approve/reject/comment on direct reports' requests, view direct reports' calendars and balances, receive coverage-conflict warnings. |
 | **HR** | Membership of a configurable Nextcloud group (default group id `hr`, set in admin settings) | Company-wide overview, statistics, exports, manage entitlements, manage public-holiday calendar, override any decision, act on escalated requests, edit/adjust any request and balance. |
 | **App admin** | Nextcloud server admins | Configure app settings (§11): HR group, leave types, escalation window, default entitlements, CalDAV target. |
@@ -72,6 +72,41 @@ There are four effective roles. A single user may hold several simultaneously
 - **No manager found:** the request is created with `manager_uid = NULL` and is
   routed directly to HR (treated as immediately escalated — see §5.4).
 
+### 2.2 Who counts as an employee (guest accounts)
+
+Not every account on an instance is a member of staff. **Guest accounts — users
+created by the [Guests app](https://github.com/nextcloud/guests) — are external
+people invited to collaborate on files. They have no entitlement and take no
+leave, so the app does not treat them as employees.**
+
+Without this rule every guest would sit in the balances report and the who's-off
+calendar forever, with an empty allowance and nothing to show.
+
+- **One definition, one place.** `EmployeeDirectory` is the only component that
+  enumerates users; `ReportService`, `EntitlementService`, `CoverageService` and
+  `ManagerResolver` all ask it rather than walking `IUserManager` themselves. A
+  rule stated in four copies is a rule that holds in three.
+- **Detection.** A guest is a user in the Guests app's own user backend, i.e.
+  `IUser::getBackendClassName() === 'Guests'` — the same thing
+  `OCA\Guests\GuestManager::isGuest()` checks. Read this way the app needs **no
+  dependency on the Guests app**: where it is absent or disabled, no account has
+  that backend and the rule is simply never true.
+- **Consequences.** Guests do not appear in balances, statistics, the sick-leave
+  overview, exports, the who's-off calendar, the HR absence list or any people
+  picker; they are nobody's direct report or peer, and cannot be resolved as a
+  line manager (a request routed to one could never be approved).
+- **Enforced, not just hidden.** The API rejects creating leave for a guest —
+  including by HR, who may otherwise record for anyone — nominating a guest as a
+  replacement, and setting a guest's entitlement. Filtering only the UI would
+  leave the rule one crafted request away from being bypassed.
+- **Pickers.** The people pickers call the app's own
+  `GET /api/employees/search` rather than core's autocomplete, because only the
+  server can tell a guest from a colleague. That endpoint wraps the same
+  collaborator search, so the admin's user-enumeration settings still apply
+  exactly as elsewhere; guests are removed from what it returns.
+- Existing records for someone who later becomes a guest are left untouched in
+  the database — they simply stop being listed.
+
 ---
 
 ## 3. Core Concepts & Data Model

appinfo/routes.php

@@ -21,6 +21,9 @@
 		['name' => 'request#reject', 'url' => '/api/requests/{id}/reject', 'verb' => 'POST'],
 		['name' => 'request#addComment', 'url' => '/api/requests/{id}/comments', 'verb' => 'POST'],
 
+		// People (autocomplete for the employee / replacement pickers)
+		['name' => 'employee#search', 'url' => '/api/employees/search', 'verb' => 'GET'],
+
 		// Balances & entitlements
 		['name' => 'balance#mine', 'url' => '/api/balance', 'verb' => 'GET'],
 		['name' => 'balance#forEmployee', 'url' => '/api/employees/{uid}/balance', 'verb' => 'GET'],