feat: one Set Password operation over the delivery queue; Synchronise Password withdrawn (#1635, layer 3 of 3)

[JayVDZ]

Summary

Layer 3 of #1635 (plan: engineering/plans/done/PASSWORD_PIPELINE_CONVERGENCE.md), stacked on #1638 and #1636. Closes #1635 when the stack lands.

• One password operation. PasswordSynchronisationServer.SetPasswordAsync(SetPasswordRequest) replaces both the immediate set-password path and the separate synchronise path. A request names accounts (Connected System Object ids) or names none, meaning every Connected System configured for Password Synchronisation. Both origins write the same queue rows, the same Activity shape (parent per change, child per system) and are delivered by the Layer 2 service.
• Explicit rows carry their account and the enable-account decision, need no Password Synchronisation configuration, use default retry settings where none exists, and are delivered even where a configuration is switched off (decision D1). Propagated rows behave exactly as before. Migration AddPasswordChangeOrigin.
• One delivery core. The open channel, security refusal, set and classify sequence lives once in PasswordDeliveryCore, used by the delivery lane and by initial password provisioning. The immediate ConnectedSystemServer set-password methods, the queue forwarders and their result DTOs are gone.
• Portal. The person page has one administrator-only Password tab: attention strip with Retry for parked changes, the Set Password card with the capable-account count, still-to-be-delivered rows with Retry and Stop trying, and history with a Set or Propagated chip. SetPasswordDialog keeps its composition (picker, generate, copy while masked, expiry, enable) and its result stage now follows the queue live: Set, Retrying with next attempt and Stop trying, Parked with the target's words and guidance, Try another password. Synchronise Password and the Actions tab are removed. The account page uses the same dialog with one target.
• REST and PowerShell. POST /api/v1/metaverse/objects/{id}/password is Set Password: password, optional connectedSystemObjectIds, expiryBehaviour (defaults differ by mode), enableAccount (named accounts only), wait (default 10 s with accounts, 0 when propagating); per-target outcome including failureReason, 200 settled or 202. The account-scoped endpoint is a one-target wrapper with the same response. Set-JIMMetaverseObjectPassword gains -ConnectedSystemId <int[]> naming accounts, the propagate default when none is named (decision D5), -Wait, and the outcome shape; -AllAccounts and Sync-JIMMetaverseObjectPassword are withdrawn; Set-JIMConnectedSystemObjectPassword returns the same shape.
• Wording (decision D4). Set Password no longer claims to store nothing: JIM holds the password encrypted only until each system has it, and keeps a refused one so it can finish the job. Dialog, endpoint remarks and docs/concepts/passwords.md say so; the "two ways to give somebody a password" section is now one operation with two target modes.
• Service Health cards, after review: uptime sits on the heartbeat line; host, version and instance id move behind a per-card details control with copy buttons; the version skew chip stays visible; no card has an empty slot.
• The person's password history is a day-grouped timeline in the Changes tab's visual language: one entry per change, an outcome pill per Connected System in the same vocabulary as Service Health, words only where something needs them, Retry and Stop trying inline.
• Changelog amended under Unreleased so 0.15.0 describes the final shape; the plan document moves to done.

Verification

• dotnet build JIM.sln: 0 warnings, 0 errors; dotnet test JIM.sln: green (see checks). RequiresPostgres fixtures for claims, origins and outcomes run against a scratch database.
• Pester: 1834 passed across the module; Lint-Changelog.ps1 and Lint-DocExamples.ps1 pass.
• Runtime on the devcontainer stack: an explicit set for one person on Panoply AD was claimed within half a second and Set within a second; the Password tab, the dialog's result stage and the history chip verified in the browser; scenario 20's latency steps passed on Layer 2 and its script now uses Set-JIMMetaverseObjectPassword.

🤖 Generated with Claude Code