v3.32.4: rebuild the link on card insertion (the first attempt)

v3.32.2 fixed the endless re-arm, but on Windows the first attempt
still failed on the old link (seen in the confirmation log: the
"self._con.connect()" traceback) and only the retry recovered - a failed
init, a 2-4 s delay and a traceback in the log.

The monitor's insert path now marks the transport stale under
_CARD_LOCK, so the first equip attempt rebuilds the PC/SC link.  It also
covers a link created at a cardless startup (never connected).  The
rebuild still happens in the equip worker, never in the pyscard monitor
thread, and _ensure_transport releases the old link first.

Docs: the READMEs' troubleshooting bullet.
Tests: an insertion marks the transport for the rebuild.
1014 Python + 953 frontend green; simple-v462.

CHANGELOG.md

@@ -9,6 +9,29 @@ every change carries a descriptive commit message.
 
 ## [Unreleased]
 
+## [3.32.4] — 2026-10-21
+
+### Fixed
+
+- A card insertion now marks the PC/SC link for a rebuild, so the **first** auto-equip
+  attempt already uses a fresh link.  On Windows the old link cannot connect after a
+  swap — v3.32.2 recovered it, but only on the second attempt, after a failed init, a
+  2–4 s delay and a traceback in the log.  A link created at a cardless startup has
+  never connected either, which the same mark covers.  The rebuild still runs in the
+  equip worker (never in the pyscard monitor thread) and `_ensure_transport` releases
+  the old link first.
+
+## [3.32.3] — 2026-10-21
+
+### Fixed
+
+- The auto-equip's captured traceback now always includes the **exception line**: cmd2
+  renders a rich-box traceback longer than the logged head, so the actual error was cut
+  off (seen in the first Windows confirmation of v3.32.2).  The tail is appended after a
+  `...` marker.
+- The "releasing the old link failed" message now says it continues with a fresh link —
+  a removed card's dead PC/SC handle always fails to disconnect.
+
 ## [3.32.2] — 2026-10-21
 
 ### Fixed