RivetMSP 26.10.19 (RivetCore 1.0.0-rc.16: pushed Mesh agent install, MSI installer)

Adopts RivetCore 1.0.0-rc.16. Two owner requests. (A) The Mesh options live only in a stamped installer, so an agent that enrolled without them, or one that updated itself, never got a Mesh agent: a technician can now push the install (and the removal) from the device page, and install it on many devices from the fleet page. (B) The server could hand out only the stamped exe: it can now also hand out an .msi, built from an uploaded MSI template.

Deploy notes: back up the database, pull this tag, composer install --no-dev --no-plugins --no-scripts, php scripts/update_cli.php --update_db (2.6.90 to 2.6.91: Core migration 0025, one new table endpoint_agent_msi_templates; safe before or right after the code, and until it runs everything works, only publishing an MSI template needs the table). No new cron line, no nginx change. Agents: a pushed Mesh install needs the rc.16 agent (an older agent shows a disabled button, "update the agent first", and the API answers 409 unsupported); the MSI needs the rc.16 setup --from-msi inside the template. Nothing changes for the exe installer or for older agents. Build the template with RivetCore's make msi (release tag agent-v* attaches it with SHA256SUMS.msi) and upload it under Administration > Endpoint agent > MSI templates (or php scripts/endpoint_agent_publish.php <file>.msi --msi --version X --arch amd64 --activate).

(A) Push the MeshCentral agent

• Device page, Remote tab (Remote access card): Install MeshCentral agent while MeshCentral is on with an https address and a device group and the device does not report the agent (disabled, with the reason, for an agent that did not announce job:mesh_install); Remove MeshCentral agent (page confirmation dialog with a box, a destructive job offered once, never retried; also offered after MeshCentral was switched off) and Run the install again once it reports the agent. The page follows the job result. The caller sends nothing but force: address, device group and pin come from the saved settings when Core creates the job, and the group id is never in the job row, the page or any result. agent/post/rmm_remote_tools.php actions mesh_install / mesh_uninstall.
• Agent fleet page, bulk install: a collapsed card (every device I may manage, a client, a tag or a group; Count the devices, tick the confirmation, Install) that shows what Core queued and what it skipped (installed, queued, agent too old, no permission, error). Capped by bulk_run_max; refused above approval_bulk_threshold (the approval queue only knows script runs). agent/post/rmm_mesh_bulk.php, js/rmm_mesh_bulk.js. Never reaches a client the user may not manage.
• Rules unchanged from Core: rmm.remote.manage and the remote-tools switch, idempotent (already_installed, already_queued), audited (Remote Tool Queued, Mesh Agent Bulk Install, Mesh Agent Installed / Install Failed).

(B) MSI installer

• Format selector exe | msi in the Add device dialog (Agent fleet page and client page) and in Administration > Deployment; the msi option is disabled, with the reason, when no template is current for the architecture (Core builds x64 only; an ARM64 PC uses the exe). The download is the template plus the payload, never a change to the stored template, named RivetIT-Agent-<client>-x64.msi; the Also install the MeshCentral agent box works the same.
• Deployment commands gain an msi block (msiexec, property form, silent downloader, uninstall, detection) for format msi.
• MSI templates card: upload, list (version, size, SHA-256, where the platform was read from), make current, deactivate, reactivate; CLI --msi. Unsigned and UNVERIFIED on Windows: the card, the dialog and the commands say so (SmartScreen; whether msiexec accepts a package with the payload appended, repair, upgrade and the custom actions have never run on Windows; RivetCore docs/rmm/MSI_VERIFY.md is the checklist).
• CSP safe (no inline handlers, no native dialogs), CSRF on every handler, labelled controls and live regions, tables scroll inside their card on a phone, nothing is drawn and no RMM query runs while the module is off.

Pin and DB: rivet/rivet-core ^1.0.0-rc.16 (lock reference cb27c541b6459b3be032bd410812328d0bbdb8bc), vendored copy identical to git archive of the tag (and installed.json / installed.php). DB 2.6.91 runs Core migration 0025 through the Core runner; db.sql gains endpoint_agent_msi_templates and the ledger row (a fresh import and the 2.6.90-to-2.6.91 update produce the same schema, no uca1400).

Tests: tests/rmm_ui.php 1755 checks (88 new, tests/rmm_ui_p16_mesh_push.php), tests/rmm_installer_ui.php 144 (59 new: the Format selector, upload and its refusals, the download with the real wixl package and the full package from make msi: OLE header, decodable trailer, stored template untouched; the Administration cards; the CLI), tests/endpoint_agent_module.php 86 (the 2.6.91 step, twenty endpoint_agent_* tables), tests/wave1_integration.php 85, a tenth browser smoke tests/browser/rmm_p16_smoke.mjs (13 checks: Remote tab install and remove with the in-page dialog, bulk, Format selector, template upload through the real file input, dark mode, phone width), and the real agent proof (98 checks, 27 new: a real rc.16 Linux agent under systemd enrolled WITHOUT Mesh is pushed mesh_install through the technician API against the mock Mesh server: wrong pin, unknown group, oversize body, the good case, node mapping, idempotence, bulk, force, removal). The agent's own Go reader decodes a PHP-stamped copy of the real make msi package. Known failures, identical on 26.10.18 (rc.15): sla_pause 2, recovery_integration 3, the strict golden replay, and check 14 of the rmm_p68_admin_smoke browser smoke.

• Not verified: a real MeshCentral (the pushed install ran against Core's mock behaviour only; the Linux agent ids, install arguments and node-id locations are as unverified as in rc.12), and anything on Windows: the pushed install on Windows, the MSI (unsigned; msiexec with an appended payload, repair, upgrade, custom actions), the Windows agent.