feat: Password Delivery Service off the worker queue (#1635, layer 2 of 3)

CHANGELOG.md

@@ -54,7 +54,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - ✨ The Connected Systems list now shows each system's Password Synchronisation state, sortable and filterable, with its parked and expired counts beside it. The four states are distinguished deliberately: a Connector that cannot set passwords, a system nobody has configured, one that is configured and switched off, and one that is delivering. Switched off is not the same as inactive, because changes keep accumulating for it, and a **Needs attention** filter cuts across the states to find the systems with work stuck behind them. (#1119)
 - ✨ A person's page now has an administrator-only Password Synchronisation tab: what is still owed to which of their Connected Systems, and what their recent password changes actually did on each one. It reads their history from Activities rather than from the queue, because a delivered change leaves the queue, and a view built on the queue alone would show a person's failures and none of their successes. (#1119)
 - ✨ Queued password changes can now be listed and summarised from the REST API and PowerShell: `GET /api/v1/password-synchronisation/queue` and `/queue/summary`, and `Get-JIMPendingPasswordChange`. A recovery across a directory that has just come back is not a job for a browser. (#1119)
-- ✨ Password Synchronisation now delivers. A password change is recorded once per Connected System the person has an account in, encrypted, and delivered by a Password Delivery task rather than in the request that made it, so nobody waits on a directory and no password change fails because one target is down. A target that was unreachable is retried with a backoff that doubles each attempt; one that refused the password, or cannot do what was asked, is parked rather than retried into the same refusal, and is released the moment the system's delivery settings change or Password Synchronisation is switched on. A change that outlives its time to live is retired with its last failure recorded, and a second password change for the same person and system replaces the first rather than queueing behind it, so only the newest password is ever sent. A system with Require Secure Transport on now refuses to send over a connection JIM cannot confirm is encrypted, leaving the work queued, rather than warning and sending anyway. (#1119)
+- ✨ Password Synchronisation now delivers. A password change is recorded once per Connected System the person has an account in, encrypted, and delivered by a dedicated Password Delivery Service rather than in the request that made it, so nobody waits on a directory and no password change fails because one target is down. The service runs on its own clock, apart from synchronisation: the first attempt follows within about a second of the change being queued, whatever import or export is running, and retries happen when they fall due rather than when the Worker is next idle. It reports its own **Worker · Passwords** card on Service Health. A target that was unreachable is retried with a backoff that doubles each attempt; one that refused the password, or cannot do what was asked, is parked rather than retried into the same refusal, and is released the moment the system's delivery settings change or Password Synchronisation is switched on. A change that outlives its time to live is retired with its last failure recorded, and a second password change for the same person and system replaces the first rather than queueing behind it, so only the newest password is ever sent. A system with Require Secure Transport on now refuses to send over a connection JIM cannot confirm is encrypted, leaving the work queued, rather than warning and sending anyway. (#1119, #1635)
+- ✨ A synchronised password change can now be waited on. `POST /api/v1/metaverse/objects/{id}/password` takes an optional `wait` (0 to 30 seconds) and `Sync-JIMMetaverseObjectPassword` gains `-Wait`, holding the call until every Connected System has settled and answering `200` with what each did with the password (set, retrying and when, parked and why, or held), or `202` with what is known so far, so a service desk script can tell the caller their reset has landed before they hang up. (#1635)
 - ✨ A Synchronisation Rule's two destructive toggles can now be previewed before they are saved. Flipping the Deprovisioning Action to Delete turns every future scope exit into a deletion in the target system, and flipping the Out-of-Scope Action to Disconnect can mass-disconnect joined objects; both were single dropdowns with no impact analysis in front of them. The rule editor's new Preview Deprovisioning Impact button reports which objects the next synchronisation would treat differently, which identities would become eligible for deletion as a result, and how many managed objects' fate on a future scope exit changes, with the counts stated on the save confirmation and the preview recorded against the change. Also available over the REST API and as `New-JIMConfigurationChangePreview -SyncRuleId`. (#1115)
 - ✨ The Pending Exports list now shows how many references each export is still owed: the count of Reference attribute changes that could not be written yet because their targets have no resolvable object in the Connected System. The wait was previously only visible by opening each export's detail page, which explains each owed reference individually. The count is also on the Pending Export list REST resource and `Get-JIMPendingExport`. (#1398)
 - ✨ An Attribute Flow's settings can now be changed after it is created, over the REST API and from PowerShell. Until now the API could add an Attribute Flow and delete one but never change one, so correcting a setting on a live Synchronisation Rule meant deleting the mapping and building it again, which discards its place in the Attribute Priority order and, on an import mapping, silently changes which contributor wins the attribute. `PATCH /sync-rules/{id}/mappings/{mappingId}` and the new `Set-JIMSyncRuleMapping` change the Expression, Missing Input Behaviour, "Null is a value", inbound value processing, case normalisation and Initial Export Only in place, leaving everything not named alone. What a mapping targets, and whether its source is an attribute or an Expression, deliberately still means delete and recreate: that revalidates against attribute types and reopens the priority position, and an edit that hid those consequences would lose them silently. A setting that cannot apply to the mapping is refused rather than ignored, as is a request naming no setting at all. (#1361)

docs/administration/deployment.md

@@ -388,9 +388,9 @@ Alternatively, add the `ports` mapping directly to `docker-compose.production.ym
 |---------------------------|-------------------------------------------------|
 | `/api/v1/health`          | Basic liveness check                            |
 | `/api/v1/health/ready`    | Readiness check (includes database connectivity)|
-| `/api/v1/system/health`   | Worker and Scheduler health from their database heartbeats (requires the Administrator role) |
+| `/api/v1/system/health`   | Health of the Worker's synchronisation loop, its Password Delivery Service and the Scheduler, from their database heartbeats (requires the Administrator role) |
 
-The `jim.web` container includes a Docker healthcheck using the readiness endpoint. The two unauthenticated endpoints answer for the web tier only; `system/health` is how the background services are observed from outside the portal, and the same report is shown on **Administration > Operations** and returned by `Get-JIMServiceHealth`. See [Operations > Service Health](../configuration/operations.md#service-health).
+The `jim.web` container includes a Docker healthcheck using the readiness endpoint. The two unauthenticated endpoints answer for the web tier only; `system/health` is how the three background services are observed from outside the portal, and the same report is shown on **Administration > Operations** and returned by `Get-JIMServiceHealth`. The `jim.worker` container hosts two of them, the synchronisation loop and the Password Delivery Service, and each reports on its own, so a Worker whose password delivery has stopped while imports still run is visible as exactly that. See [Operations > Service Health](../configuration/operations.md#service-health).
 
 The `jim.worker` and `jim.scheduler` containers use file-based healthcheck monitoring. Each service writes a heartbeat file periodically during normal operation, and the Docker healthcheck verifies the file is recent. This means `docker compose ps` and orchestrators like Docker Swarm or Kubernetes can detect when a worker or scheduler has stalled, even if the process itself has not exited.
 

docs/api/index.md

@@ -48,12 +48,12 @@ These behaviours are common across the API. The interactive API reference is aut
 
 **Enum values.** Enum-typed fields are always serialised as their string name in responses (for example `"status": "Enabled"`), and must be sent as their string name in request bodies. Numeric enum values are not accepted on input and are rejected with a `400 Bad Request`; this keeps the wire contract stable, since an enum's numeric ordinal is free to change between releases while its name is not.
 
-**Asynchronous operations.** Long-running operations (schema import, Run Profile execution, Connected System deletion) return `202 Accepted` with an activity ID; poll [Activities](../configuration/activities.md) to track progress.
+**Asynchronous operations.** Long-running operations (schema import, Run Profile execution, Connected System deletion) return `202 Accepted` with an activity ID; poll [Activities](../configuration/activities.md) to track progress. Synchronising a password (`POST /api/v1/metaverse/objects/{id}/password`) is the one operation that can be asked to wait: pass `wait` (seconds, 0 to 30, default 0) and it answers `200` once every target Connected System has settled, or `202` with what is known when the time runs out; see [Passwords](../concepts/passwords.md#-starting-a-synchronised-password-change) for the per-target states in the body.
 
 **Rate limiting.** Requests are throttled per client (see [Rate Limiting](rate-limiting.md)); an exceeded limit returns `429 Too Many Requests` with a `Retry-After` header.
 
 ## System endpoints
 
 A small set of system-level endpoints (health, readiness, liveness, version, auth config, user info) are useful for orchestrators, load balancers, and client bootstraps rather than identity management workflows. They are documented in the interactive API reference alongside everything else.
 
-The unauthenticated health endpoints answer for the web tier only. `GET /api/v1/system/health` (Administrator role) reports whether the Worker and the Scheduler are alive and what each is doing, from the heartbeats they write to the database; it is the endpoint for monitoring that needs to know whether JIM's work is actually being done. See [Operations > Service Health](../configuration/operations.md#service-health) for what each status and condition means.
+The unauthenticated health endpoints answer for the web tier only. `GET /api/v1/system/health` (Administrator role) reports whether the Worker's synchronisation loop, its Password Delivery Service and the Scheduler are alive and what each is doing, from the heartbeats they write to the database; it is the endpoint for monitoring that needs to know whether JIM's work is actually being done. See [Operations > Service Health](../configuration/operations.md#service-health) for what each status and condition means.