fix(efuse): connect U13's exposed thermal pad to GND

The TPS25961's exposed pad is GND and the datasheet requires it be connected
to the GND plane (Table 5-1; package note 3 adds a mechanical requirement).
REVIEW.md claimed this was honoured because the footprint is the _ThermalVias
variant -- but the variant alone connects nothing.  hardware/TPS25961.kicad_sym
defined pins 1-6 only, with no pin for the exposed pad, so KiCad had nothing to
map onto footprint pad 7 and left it netless: an isolated copper island under
the chip with its thermal vias going nowhere.

Adds pin 7 (GND, power_in, hidden, stacked on pin 4) to the symbol library, the
cached symbol in exi.kicad_sch, and the U13 instance.

PCB updated and verified: U13 pad 7 carries GND on all four elements (both SMD
rects and both thermal vias), R48 placed, EFUSE_OVLO routed, R49 gone.  DRC
reports 0 violations, 0 unconnected pads and 0 schematic parity issues -- the
0-unconnected result is what confirms pad 7 is tied into the GND network rather
than merely labelled.  The 4 DRC errors previously dismissed as zone-fill
phantoms on this pad are gone, though zones were refilled in the same pass so
that is not proof of cause either way.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

hardware/re-bba-rb/REVIEW.md

@@ -405,8 +405,26 @@ datasheet extraction, WebSearch/WebFetch for parts and reference designs.
     beyond that use an FPGA-read divider, not the eFuse enable.
   - **OVLO tied directly to GND** = internal fixed OV threshold. Note the OVLO
     pin's absolute maximum is only **6.5 V** — it must never see the 12 V rail.
-  - **Thermal pad must connect to the GND plane** (datasheet requirement); the
-    chosen footprint is the `_ThermalVias` variant for this reason.
+  - ⚠️ **Thermal pad must connect to the GND plane** (datasheet requirement).
+    The `_ThermalVias` footprint variant was chosen for this reason — **but
+    that alone connected nothing, and the pad was floating until 2026-10-02.**
+    `hardware/TPS25961.kicad_sym` defined **pins 1–6 only**, with no pin for the
+    exposed pad, so KiCad had nothing to map onto footprint pad 7 and left it
+    netless: an isolated copper island under the chip with its thermal vias
+    going nowhere. Datasheet Table 5-1: *"GND | PAD | Thermal/Ground — the
+    exposed pad is used primarily for heat dissipation and must be connected to
+    GND plane on the PCB"*; package note 3 adds *"must be soldered to the PCB
+    for thermal and mechanical performance"*.
+    **Fixed 2026-10-02:** added **pin 7** (GND, `power_in`, hidden, stacked on
+    pin 4 at the same coordinates) to `hardware/TPS25961.kicad_sym`, to the
+    cached symbol in `exi.kicad_sch`, and as a `(pin "7")` entry on the U13
+    instance. Netlist now shows **U13 pins 4 AND 7 on GND**; ERC 0 violations.
+    **PCB ACTION REQUIRED: run *Update PCB from Schematic*** so pad 7 takes the
+    GND net — until then the pad is still isolated on the board.
+    Thermally this is not critical at the measured 56 mA load (steady-state
+    loss ≈ 0.3 mW), but it matters in a fault: with no heat path the FET hits
+    thermal shutdown sooner, changing the current-limit / 3-retry / latch-off
+    behaviour. The mechanical requirement stands regardless.
   - Symbol: no TPS25961 exists in the KiCad libraries (the stock `TPS2596xx`
     is an 8-pin SO-8 with a different pinout — do not substitute it), so
     `hardware/TPS25961.kicad_sym` was created and registered in
@@ -451,11 +469,22 @@ datasheet extraction, WebSearch/WebFetch for parts and reference designs.
   GUI refills all zones before DRC**, so the GUI (the authority) shows these
   clean. Confirmed 2026-08-02: a command-line DRC reported 18 such
   "errors" (14 GND-vias-over-3V3, 4 on U13's thermal pad) on a board the GUI
-  reports clean. If you must DRC from the CLI, open the board in the GUI, run
+  reports clean. **RESOLVED 2026-10-02:** after the thermal-pad fix (§6) and
+  a PCB update, a CLI DRC reports **0 violations, 0 unconnected pads, 0
+  schematic parity issues** — the U13 four are gone. Note the zones were also
+  refilled in the same pass, so this does NOT prove the netless pad caused them
+  rather than the stale fill; both changed at once. What it does confirm is
+  that pad 7 now carries GND on all four elements AND counts as connected
+  (0 unconnected pads), i.e. it is tied into the GND network rather than
+  isolated. If you must DRC from the CLI, open the board in the GUI, run
   "Fill All Zones" (B), save, THEN run `kicad-cli` — or just trust the GUI.
   The board is DRC-CLEAN in KiCad.
-- **DRC (GUI, authoritative)**: 0 errors / 0 unconnected / 0 parity. Warnings
-  are silkscreen cosmetics only (~150–170; JLC auto-clips).
+- **DRC: 0 errors / 0 unconnected / 0 parity** (CLI, 2026-10-02, after the
+  eFuse rework — zones were current in the saved file so the CLI agreed with
+  the GUI for once). Warnings are silkscreen cosmetics only: **293** as of
+  2026-10-02 (199 `silk_overlap`, 89 `silk_over_copper`, 5
+  `silk_edge_clearance`), up from ~150–170 before the rework. JLC auto-clips
+  these; the rise is placement churn, not a new fault.
 - **JLC capability floor**: encoded as error-severity rules in
   `re-bba-rb.kicad_dru` (0.09 mm trace/space, 0.15 mm drill, 0.2 mm
   hole-to-copper etc.) — passing. Diff-pair impedance rules (USB 90 Ω,