Persist Phase 2 system telemetry

Adds rebootreasonsjson, bootinfojson and defenderjson with their migration in the same change, so the model never references a column the schema has not applied.

rebootreasons is not redundant with the existing pendingreboot column. That column is a single bool OR-ed from three registry signals and cannot say which fired, and the difference matters: a staged file rename means the box is mid-servicing, while a lone servicing key can sit set for weeks on a machine nobody rebooted.

Null means never reported and is deliberately distinct from an empty list, which means checked and nothing pending. Backfilling [] would assert every pre-existing endpoint was confirmed clean.

plugins/endpoints/migrations/versions/0015_endpoint_system_telemetry.py

@@ -0,0 +1,78 @@
+"""Add rebootreasonsjson, bootinfojson and defenderjson to endpointstates.
+
+Phase 2 system-side telemetry. All three are collect-and-persist; none is
+surfaced in the UI by this change.
+
+rebootreasonsjson is NOT redundant with the existing pendingreboot column. That
+column is a single boolean OR-ed from three registry signals, so it cannot say
+which one fired, and the difference is operationally significant: a
+PendingFileRenameOperations entry means files are staged for replacement on the
+next boot, so the machine is mid-servicing, whereas a lone Component Based
+Servicing or Windows Update key can sit set for weeks on a box nobody has
+rebooted. Same boolean, very different urgency.
+
+bootinfojson exists because uptime lies under fast startup - a machine reports
+days of uptime after what the operator experienced as a shutdown, and a "reboot"
+that was really a hybrid resume does not clear the driver or kernel state a
+support call is usually trying to clear.
+
+defenderjson is stored deliberately unsurfaced. Defender is known to produce
+false positives in this environment, so wiring it to a card now would train
+operators to ignore that card; persisting it starts the history accumulating for
+whenever someone is ready to interpret it.
+
+JSON rather than scalars: reboot reasons is a variable-length list, and the boot
+and Defender payloads are small related groups that are read together and would
+otherwise be six sparse columns.
+
+MEDIUMTEXT for consistency with the other snapshot columns on this table.
+
+Nullable with no backfill. Null means never reported, which is deliberately
+distinct from an empty list (checked, nothing pending) - defaulting the reboot
+reasons to [] would assert every pre-existing endpoint was confirmed clean.
+
+Idempotent: each column-add checks the live schema first, so a re-run and a
+db.create_all() site both stay clean on strict MySQL 8.
+"""
+from alembic import op
+
+import sqlalchemy as sa
+
+
+# revision identifiers, used by Alembic.
+revision = 'endpoints0015systemtelemetry'
+down_revision = 'endpoints0014diskhealth'
+branch_labels = None
+depends_on = None
+
+TABLE_NAME = 'endpointstates'
+
+_COLUMNS = (
+    'rebootreasonsjson',
+    'bootinfojson',
+    'defenderjson',
+)
+
+
+def _has_column(table_name, column_name):
+    from sqlalchemy import inspect
+
+    inspector = inspect(op.get_bind())
+    if not inspector.has_table(table_name):
+        return False
+    return any(col['name'] == column_name
+               for col in inspector.get_columns(table_name))
+
+
+def upgrade():
+    for column_name in _COLUMNS:
+        if not _has_column(TABLE_NAME, column_name):
+            op.add_column(
+                TABLE_NAME,
+                sa.Column(column_name, sa.Text(length=16777215), nullable=True))
+
+
+def downgrade():
+    for column_name in reversed(_COLUMNS):
+        if _has_column(TABLE_NAME, column_name):
+            op.drop_column(TABLE_NAME, column_name)