Power inference: classify rail+control names as power-adjacent, not suspect

Names holding both a rail token (VCC/VDD/PWR/...) and a control token
(SENSE, EN, PG, FB, OK, FAULT, ...) are signals ABOUT a rail - feedback,
enable, power-good - so their non-Power classification is confident.
They used to land in the Suspect bucket, drowning the genuine ambiguities.

- classify_signal_name(): 3-state name verdict (Rail / PowerAdjacent /
  GndShield / Other) with whole-token matching (trailing digits stripped,
  long lexemes also match as suffix: VSENSE, PWRGOOD, NFAULT).
  infer_signal_type() becomes a thin wrapper, so the dashboard suspect
  count and the export suspect column shrink automatically.
- infer_signal_types(): PowerAdjacent -> Other + new `adjacent` stat,
  before the structural gate (a big-fanout sense net stays Other).
- LoadResult.adjacent rendered by all three consumers (TUI command,
  script engine, wx log) - outputs kept in sync.
- analyze Types tab: new [Pwr-adjacent] rows with the deciding token,
  deliberate sort order (Power, Suspect, Adjacent, Gnd), glossary entry.

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

src/core/app/script.cpp

@@ -189,7 +189,9 @@ private:
                                 + " singleton/NC signal(s))" : ""));
             emit("  types:   " + std::to_string(r.power) + " power, "
                  + std::to_string(r.gnd) + " gnd, " + std::to_string(r.kept_other)
-                 + " suspect Power (name only — kept as Other)");
+                 + " suspect Power (name only — kept as Other), "
+                 + std::to_string(r.adjacent)
+                 + " power-adjacent (control — kept as Other)");
             return true;
         }
         if (cmd == "connect" || cmd == "plug") {