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>

.devcontainer/Dockerfile

@@ -24,6 +24,8 @@ RUN apt-get update && apt-get install -y --no-install-recommends \
 # (FT2232H EEPROM).  sudo: the /dev/bus/usb nodes are root-owned, so the vscode
 # user flashes via `sudo` (NOPASSWD, configured below).
 
+ENV TZ="Europe/Amsterdam"
+
 # Debian marks the system Python as externally-managed (PEP 668), so install
 # project deps into a venv. /opt/venv is first on PATH, so `python`/`pip` resolve
 # to it for all users.

hardware/TPS25961.kicad_sym

@@ -185,6 +185,25 @@
 					)
 				)
 			)
+			(pin power_in line
+				(at 0 -17.78 90)
+				(length 5.08)
+				(hide yes)
+				(name "GND"
+					(effects
+						(font
+							(size 1.27 1.27)
+						)
+					)
+				)
+				(number "7"
+					(effects
+						(font
+							(size 1.27 1.27)
+						)
+					)
+				)
+			)
 		)
 		(embedded_fonts no)
 	)

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
+  - ⚠️ **Thermal pad must connect to the GND plane** (datasheet requirement).
-    chosen footprint is the `_ThermalVias` variant for this reason.
+    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
+- **DRC: 0 errors / 0 unconnected / 0 parity** (CLI, 2026-10-02, after the
-  are silkscreen cosmetics only (~150–170; JLC auto-clips).
+  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 Ω,

hardware/re-bba-rb/TODO.md

@@ -261,7 +261,13 @@ schematic changes.
       Verified after the edit: nets are 12V_RAW(R46.2) / EFUSE_EN(R46.1, R47.1,
       U13.5) / EFUSE_OVLO(R47.2, R48.1, U13.2) / GND(R48.2, R45.2, U13.4);
       component count 150 -> 151 with nothing dropped; ERC 0 violations.
-      **PCB TODO:** place R48 near U13, route the new EFUSE_OVLO net, and
+      **Also fixed 2026-10-02:** U13's exposed thermal pad had NO NET — the
+      custom symbol defined pins 1–6 only, so footprint pad 7 was an isolated
+      island despite the `_ThermalVias` footprint. Added pin 7 (GND, hidden,
+      stacked on pin 4); datasheet says the pad *"must be connected to GND
+      plane"*.
+      **PCB DONE 2026-10-02** — R48 placed, EFUSE_OVLO routed, pad 7 on GND
+      (all 4 elements), DRC 0 errors / 0 unconnected / 0 parity. Remaining:
       re-export BOM + CPL (reapplying CPL_ROTATIONS.md afterwards).
       Gives **UVLO 6.78 V** and **OVLO 15.18 V typ (14.47–15.78 worst case)**
       — under U3's 17 V input rating, which is what actually caps the OVLO

hardware/re-bba-rb/exi.kicad_sch

@@ -1313,6 +1313,25 @@
 						)
 					)
 				)
+				(pin power_in line
+					(at 0 -17.78 90)
+					(length 5.08)
+					(hide yes)
+					(name "GND"
+						(effects
+							(font
+								(size 1.27 1.27)
+							)
+						)
+					)
+					(number "7"
+						(effects
+							(font
+								(size 1.27 1.27)
+							)
+						)
+					)
+				)
 				(pin input line
 					(at -15.24 0 0)
 					(length 5.08)
@@ -3212,6 +3231,9 @@
 		(pin "6"
 			(uuid "261b68e5-edb3-425a-b550-6416e801c1f3")
 		)
+		(pin "7"
+			(uuid "379caeec-e2fa-4b96-9dac-3674b3d9eb77")
+		)
 		(instances
 			(project "re-bba-rb"
 				(path "/dbb182a6-d579-468e-b98b-6f0950da9e3a/1b071f68-b4ea-469c-942f-de06380c9077"