Document Phase 2 system telemetry

Records why rebootreasons is not redundant with pendingreboot, why bootinfo carries two facts that must not be collapsed, and why defender is stored unsurfaced.

Also corrects the notes: pending file-rename was already being collected and OR-ed into pendingreboot, so the gap was that the stronger signal was flattened into the weaker one rather than missing. Records that the columns landed as 0015 because 0014 was taken by disk health earlier in this phase.

plugins/endpoints/AGENT-CONTRACT.md

@@ -68,6 +68,18 @@ arrays. `adopt` is first-contact only.
   "osinfo": { /* opaque object: build, version, install date */ },
   "domain": "shopfloor.example.com",  // domain or workgroup membership
   "pendingreboot": false,             // omit when unknown; absent != false
+  "rebootreasons": [],                // [] = checked, nothing pending; see notes
+  "bootinfo": {
+    "hiberbootenabled": false,        // fast startup CONFIGURED
+    "lastboottype": "Cold"            // what the last boot DID: Cold|Fast startup|Resume|Unknown
+  },
+  "defender": {                       // persisted, deliberately not surfaced
+    "serviceenabled": true,
+    "realtimeenabled": true,
+    "signatureagedays": 0,            // real 0 = updated today; null = did not report
+    "antispywareagedays": 0,
+    "quickscanagedays": 0
+  },
   "diskhealth": [                     // per PHYSICAL device; see notes
     {
       "deviceid": "0",
@@ -144,6 +156,28 @@ Notes:
   genuinely empty now"; omit when you simply did not collect it this cycle.
 - `pendingreboot` follows that rule strictly: omit it when the check failed. A
   literal `false` asserts the endpoint is confirmed NOT holding a reboot.
+- `rebootreasons` is NOT redundant with `pendingreboot`. That key is a single
+  bool OR-ed from three registry signals and cannot say which fired, and the
+  difference is operational: `pendingfilerename` means files are staged for
+  replacement on next boot, so the box is mid-servicing, while a lone
+  `componentbasedservicing` or `windowsupdate` key can sit set for weeks on a
+  machine nobody has rebooted. Same boolean, very different urgency. An EMPTY
+  array means checked and nothing pending; OMIT the key when the check failed.
+- `bootinfo` carries two distinct facts that must not be collapsed:
+  `hiberbootenabled` is whether fast startup is CONFIGURED (registry, always
+  readable) and `lastboottype` is what the last boot ACTUALLY did (Kernel-Boot
+  event 27). The registry cannot tell you what the last boot did, and the event
+  may have aged out of the log, so neither substitutes for the other. This
+  exists because uptime LIES under fast startup: a box reports days of uptime
+  after what the operator experienced as a shutdown.
+- `defender` is stored but deliberately NOT surfaced. Defender produces known
+  false positives in this environment, so wiring it to a card now would train
+  operators to ignore that card. Signature/scan ages are in DAYS; a real `0`
+  means updated today, so send `null` when Defender did not report rather than
+  defaulting to zero.
+- `interfaces` entries gained `linkspeedbps` and `fullduplex`, paired on by MAC
+  from `MSFT_NetAdapter`. Both are `null` when link state was unreadable or the
+  adapter is disconnected - an unknown duplex must not read as half-duplex.
 - `diskhealth` is per PHYSICAL device and is NOT the same list as `disks`, which
   is per volume. One physical drive can back several volumes or none the
   operator sees, so the two do not share a key and are not merged.