Fixes the GC/USB power led handover

hardware/re-bba-rb/BRINGUP.md

@@ -69,7 +69,7 @@ the impedance-matching resistors — wrong part for an LED.) The RGB LED
 part of this complaint. BOM/PCB change for V2; a rework could tack larger
 resistors on this unit if the brightness is a bench nuisance.
 
-### 2. GC_ON is not the clean on/off the gateware assumed (sits at 2.3 V; both handover LEDs on)
+### 2. GC_ON was not a clean on/off (sat at 2.3 V; both handover LEDs on) — FIXED in schematic 2026-08-28
 
 **Observation:** `GC_ON` measures **2.3 V** (not a clean rail). With **both USB
 and GC connected**, both transistor-driven LEDs (D8, D9) are lit — the intent
@@ -83,17 +83,29 @@ U12.3, FPGA **U9 pin 21**, pulled up by R5 10 k to 3V3; drives Q1 base via R39
   when base ≲2.6 V) **both conduct** → both D8 and D9 light. There is no clean
   one-or-the-other point at this intermediate voltage.
 
-**Two things to resolve:**
-- **Hardware:** the complementary-transistor indicator doesn't give a clean
-  handover display at the actual GC_ON level. Re-think for V2 (e.g., a comparator
-  / proper level, or drive the two indicators from a real one-hot power-source
-  signal). First confirm what GC_ON's ST pin actually does across the USB-only /
-  GC-only / both states (TPS2116 ST semantics — see REVIEW.md).
-- **Gateware:** GC_ON is wired to FPGA pin 21 but **not yet used**. The planned
-  "gate all outputs on GC_ON" (see TODO.md) assumed GC_ON is a clean logic level.
-  2.3 V is above the iCE40 3.3 V-LVCMOS V_IH (~2.0 V) so pin 21 would read HIGH,
-  but it's marginal and the semantics aren't the assumed on/off. Verify the real
-  signal before relying on it for output gating.
+**Root cause (identified 2026-08-28):** the intermediate ~2.3 V is **base-loading
+of the open-drain ST node**. When GC is the source, ST is Hi-Z and *should* sit at
+3V3 (R5 pull-up), but Q1's base (through R39 10 k) drags it down — R5‖R39 divide
+3V3 to ~2.0 V — which is low enough that the PNP Q2's V_EB ≈ 1.3 V and it conducts
+too. So both LEDs light, and the FPGA/EN see a soggy 2 V instead of 3V3.
+TPS2116 ST is only characterised to sink **1 mA** (DS: V_OL @ I_ST = 1 mA,
+t_ST @ R_ST = 10 k), so simply strengthening R5 is not allowed.
+
+**Hardware fix — APPLIED 2026-08-28 (schematic):** raise the base resistors and
+modestly lower the pull-up so GC_ON swings clean while ST stays ≤1 mA:
+- **R5 10 k → 5.1 k** (C25905, reuses R6/R7 part)
+- **R39 / R40 10 k → 33 k** (C25779, reuses R1 part)
+Result: GC active → GC_ON ≈ **2.95 V** → Q1 saturates (D8/GC lit), Q2 V_EB ≈
+0.35 V → OFF (D9/USB dark); USB active → ST low (sinks ~0.73 mA < 1 mA) → D9 lit,
+D8 dark. Clean one-hot. **No new BOM lines, no PCB layout change** (resistor value
+swaps only — run "Update PCB from Schematic" so the F.Fab values match). This also
+**resolves the gateware concern below**: GC_ON now reads a solid ~2.95 V (well
+above the iCE40 V_IH) instead of a marginal 2.3 V. D8/D9 = GC/USB is the confirmed
+assignment (TPS2116 ST "low when VIN1 not used", VIN1 = GC priority — see
+REVIEW.md); the B.SilkS labels are correct.
+- ~~**Gateware:** GC_ON marginal at 2.3 V for the FPGA pin-21 read~~ — addressed
+  by the fix above (now ~2.95 V). The "gate all outputs on GC_ON" work (TODO)
+  can now assume a clean level; still verify on the reworked bench unit.
 
 ### 3. Functional W5100 test — send a packet capturable in Wireshark (works around broken D3?)