List recent alarm notifications

Lists your project's out-of-bed notifications, filtered and paged. Out-of-bed is evaluated and recorded by Ovok as CommunicationRequests, and this is its feed. Medical notifications are not here; read `GET /v1/slim/notifications/medical` for those. **Auth:** Bearer token. The caller must be a practitioner, an admin, a super admin, or hold the "System Owner" access policy. The access policy must grant `CommunicationRequest:read`, `CommunicationRequest:search` and `Observation:read` (an admin or super admin who holds no access policy skips this check). **Scope:** The caller's project (from the token). The `project` query parameter is accepted but ignored. ## Behaviour - The notification type is fixed to out-of-bed; there is no `type` parameter. Prefer this route over the deprecated `GET /v1/slim/notifications?type=outOfBed`. - `status=active` lists the new notifications and `status=completed` the reviewed ones. Leave `status` out to list new and reviewed together; each row keeps its own `status`. An episode closed by hand without an acknowledgement is `revoked`, so it is in none of these lists; ask `status=revoked` for it. An episode that has ended but has not been acknowledged stays `active`, with an end-of-episode marker, so one resident can have more than one active row. - One row per out-of-bed episode, not per reading: the resident's open episode is updated in place. - Sort order: newest first by event time (`occurrenceDateTime`, then `authoredOn`, then id). - `patient` takes a Patient id or `Patient/{id}`. `device` takes a Device id, `Device/{id}`, or the device's identifier value. A Device id that does not exist returns an empty page rather than an unfiltered one. `device` matches the device that raised each alert, and each row's device and room are that device's, also after the resident moved to another device or was unassigned. - `startDate` and `endDate` are inclusive ISO 8601 UTC instants, used exactly as sent. They bind to the episode's last firing time (`occurrenceDateTime`), whatever the status. Either may be omitted. A missing `startDate` defaults to one year back for `status=active` and 30 days back otherwise. Without `status`, the new rows keep the one-year default and the reviewed rows the 30-day one, so the list holds exactly the rows of `status=active` and `status=completed` together. - Paging: `page` from 0, `count` from 1 to 100 (default 25). `total` is an exact count for the filter, the same on every page, cached for 15 seconds. It counts matching CommunicationRequests, so it is an upper bound on the rows you can page through. It reads `0` if the count lookup fails; the rows are unaffected. - The list pages through at most the first 1,000 results (server-configurable). `total` is clamped to that cap. When the cap or the per-request scan limit stops a page short, `truncated` says why: `{ reason: 'result-cap', limit }` or `{ reason: 'scan-budget', limit }`. `truncated` is `null` when the page is complete. - Acknowledge a row with `PATCH /v1/slim/notifications/{id}/ack`. ## Example ```bash curl -X GET 'https://api.sandbox.ovok.com/v1/slim/notifications/oob?status=active&page=0&count=25' \ -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3NjcyNjg4MDAsImV4cCI6MTc2NzI3MjQwMH0.Ql3B_ztDvctlyZ2z0vp4sl3ExXRQGkzmxdmTAqxNzZk' ```