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.