feat(flex): send SmartSDR's spot priority; fix(chase): the same station on the same slot has nothing left to give

The panadapter has finite room: spots close in frequency are stacked
behind a '+' and only one is drawn, chosen by PRIORITY — a parameter
'spot add' accepts and OpsLog never sent. So a new entity sat invisible
behind three stations already in the log. DXHunter has sent it for
years; the tiers here are the same idea in the operator's own words:
the entity never worked (with my own callsign, for a multi-op), then
band/mode/slot, then the reference hunts, then everything else.

And a callsign already worked on this exact band and mode stops
advertising a need. Working it again cannot turn a missing QSL into a
confirmation — the QSO is already there — so shouting NEW DXCC over a
station worked an hour ago only teaches an operator to distrust the
colour. The need is real and stays on every OTHER station of the entity,
which is where it can be answered. Applied on both paths out of the
verdict, including the early one that leaves the loop first.

internal/cat/cat.go

@@ -304,6 +304,14 @@ type SpotInfo struct {
 	BackgroundColor string
 	Comment         string
 	LifetimeSec     int // panadapter display seconds before auto-removal (0 = backend default)
+	// Priority is SmartSDR's own tie-breaker, 1 (highest) to 5.
+	//
+	// It matters because the panadapter has finite room: spots close in
+	// frequency are stacked behind a "+" and only one of them is drawn. The
+	// radio picks that one by priority — so an entity never worked can sit
+	// invisible behind three stations already in the log unless we say which
+	// is worth the space. 0 leaves the field off the command entirely.
+	Priority int
 }
 
 // Spotter is an OPTIONAL backend capability: show cluster spots on the radio