docs: drop the changelog entry that a union merge brought back (#1119)

CHANGELOG.md

@@ -29,7 +29,6 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - ✨ **JIM composes `objectClass` on export, so a merged class arrives with the attributes that justify it.** Creating an entry writes the Object Type's own class plus every merged auxiliary class whose attributes that create is writing, and an existing entry gains a class in the same modify that first flows one of that class's attributes. There is no pass that stamps a class onto every entry, because adding a class an entry cannot satisfy is itself an `objectClassViolation`. At the moment a class is added its required attributes are enforced: an export that would leave the entry invalid is refused with an error naming exactly what is missing, rather than being sent for the directory to reject in terms an administrator cannot act on. `objectClass` is correspondingly refused as an Attribute Flow target, in the same way credential attributes are, because no single flow can state an answer that differs entry by entry. Restricting a class to some entries is done with Synchronisation Rules: the class only ever follows its attributes. (#492)
 - ✨ **Provisioning objects whose identity is an auxiliary class.** Some populations are defined by an auxiliary class on a generic structural carrier rather than by a structural class of their own; JIM could already import them and could not create them, because every directory entry must carry exactly one structural class and JIM had not been told which. Such an Object Type's sub-tab now carries a **Structural Carrier Class** field naming the class to write alongside it, so a create writes both. Until one is chosen the Object Type says so and stays import-only. Also available as `Set-JIMConnectedSystemStructuralCarrierClass` and the `object-types/{id}/structural-carrier` endpoint. (#492)
 - ✨ **Auxiliary class discovery, to find which classes a directory's entries actually carry.** A directory's schema says which auxiliary classes exist, not which are in use, and on a large estate that can be dozens of classes to reason about. Discovery reads entries and reports how many carry each class, as a suggestion beside each one; it changes no configuration. Two scopes, because LDAP cannot random-sample: a quick sample reads the first entries of each Object Type and is fast but cannot prove a class unused, and a full scan reads every entry in scope asking for class membership alone. A run reports against an Activity with progress and cancellation, and a cancelled run keeps what it found. JIM also reads the directory's DIT Content Rules, where it publishes them, and marks the classes they permit. Both kinds of suggestion are advisory: every auxiliary class in the schema is offered whether or not anything suggests it. Available as `Start-JIMConnectedSystemAuxiliaryClassDiscovery` and `Get-JIMConnectedSystemAuxiliaryClassDiscovery`, and the `auxiliary-class-discovery` endpoints. (#492)
-- ✨ Password Synchronisation history is now kept under its own retention period, `History.PasswordEventRetentionPeriod`, defaulting to a year. It governs two things together: the Activities recording what happened to each password change, and the queue rows that finished (parked, expired or cancelled). Its own class rather than the general history period because the question these answer, "was this person's password ever set in that system, and if not, why?", is asked long after the synchronisation history around them stops being interesting. It is also what bounds how long JIM holds a password it can no longer deliver: a parked or cancelled row still carries its encrypted value, so shortening the period is how you shorten that. Changes still owed to a Connected System are never removed, however old. See [How long any of it is kept](https://docs.junctional.io/concepts/passwords/#-how-long-any-of-it-is-kept). (#1119)
 - ✨ Password Synchronisation can now be configured per Connected System. A new Passwords tab, REST resource and `Get-/Set-JIMConnectedSystemPasswordSynchronisation` set which Object Type holds the accounts, how many delivery attempts to make and how long to wait between them, and whether to refuse to transmit over a connection JIM cannot confirm is encrypted. The enable toggle is deliberately separate from the configuration, so a system can be set up ahead of a change window and switched on during one; disabling is the supported way to stop delivery, because removing a configuration would discard everything queued against it. The tab appears only on Connected Systems whose connector can set passwords. (#1119)
 - ✨ A Synchronisation Rule now warns when one of its Attribute Flows targets an attribute whose name suggests it carries a password, pointing at Password Synchronisation instead. The well-known credential attributes were already blocked outright, but a renamed or unfamiliar one could still be flowed as ordinary data, which stores the secret in Metaverse and Connected System Object attribute values, both change histories, Pending Exports, export previews, search results and database backups. The rule stays valid: the check matches on a name, so it advises rather than refuses. (#1119)
 - ✨ You can now preview a Connected System schema change before you save it. Deselecting an Object Type or an attribute is the rare configuration change with no visible effect at all: nothing fails, nothing is deleted and nothing is disconnected, JIM simply stops reading, and everything downstream carries on over data that has stopped moving. **Deselecting an Object Type does not take its objects out of management**: they stay joined to their Metaverse Objects and go on contributing the values they last imported, which never refresh again. The preview says so, and puts a number against it: how many Connected System Objects would stop being imported, which attributes would stop being refreshed and on how many objects (counting only the objects that actually hold a value for them), and whose contributed Metaverse values would be withdrawn, or kept, when their obsolete objects are next synchronised. It names what would go on running over the frozen data too: Synchronisation Rules still bound to the Object Type, and Attribute Flow mappings still reading the attribute. Available from **Preview Changes** on the Schema tab, over REST at `POST /synchronisation/connected-systems/{id}/schema-selection/preview`, and from PowerShell with `New-JIMConfigurationChangePreview -ConnectedSystemId <id> -SchemaObjectType <types>`. See [What deselecting means](https://docs.junctional.io/configuration/connected-systems/#what-deselecting-means). (#1475)