fix(multi-site): promotion no longer orphans the demoted old master's LDAP replication

Found while auditing the new LDAP MMR auto-config for gaps: neither
POST /site-promote nor POST /demote ever touched SiteSpoke. Two real
problems:

1. The demoted old master got a fresh masterJoinKey but was never
   registered as a spoke of the new master -- no SiteSpoke row, no
   ldapServerId, invisible to GET /ldap-peers's peer list. It also
   structurally could not self-heal: POST /join refuses re-join for a
   node that's already a spoke, and separately requires a fresh
   install (siteIsFresh()) -- neither true for a former master with
   real users/agents. Fixed: /demote now registers itself with the new
   master immediately (POST /spokes), the same way a real join does,
   deriving its own endpoint from stack.selfUrl (override) or
   https://stack.ssoHost (the normal case).

2. The promoted node's live OpenLDAP ServerID doesn't change --
   GET /ldap-replication-config starts advertising 1 for it
   immediately (derived purely from cfg.isMaster), but nothing
   restarts slapd with that value (OpenLDAP's static slapd.conf only
   reloads at process start, and this app has no safe way to restart
   its own container). Can't be fixed in-process; surfaced instead --
   /site-promote's response now includes ldapReplicationNote telling
   the operator to re-run setup.sh promptly.

Verified against real running containers (docker-compose.multisite-e2e.yml):
after promotion, the demoted old master correctly appears in the new
master's LDAP peer list with a real assigned ldapServerId.

nodejs/routes/api_directory_admin.js

@@ -1116,6 +1116,16 @@ router.post('/site-promote', async (req, res, next) => {
       status: 'ok',
       message: 'Node successfully promoted to Master Site',
       handoff: handoffNote,
+      // This node's own OpenLDAP ServerID stays whatever it was as a spoke
+      // (e.g. 2) until `setup.sh` is re-run here -- GET
+      // /ldap-replication-config will immediately start advertising 1 for
+      // this node (the master's reserved ID) since that's derived purely
+      // from cfg.isMaster, but nothing restarts slapd with the new value
+      // automatically (OpenLDAP's static slapd.conf is only read at process
+      // start, and this app has no safe way to restart its own container).
+      // Surfaced here + on the Multi-Site modal so an operator promoting a
+      // site knows to re-run setup.sh promptly, not just assume it's done.
+      ldapReplicationNote: 'Re-run setup.sh on this node to apply its new LDAP ServerID (1) and pick up the current spoke peer list -- OpenLDAP config only reloads at process start.',
       config: {
         isMaster: true,
         masterUrl: '',