fixes tuduce#123 probably as well. to be tested.

…collisions

GuessIcaoTypeFromTitle/GuessIcaoAirlineFromText stripped spaces (and
dashes) before searching, which could glue two unrelated words together
at their seam and coincidentally match a real but unrelated designator
- e.g. "Airbus A32NX..." stripped to "AirbusA32NX..." spuriously matched
"SA3" (Stits SA-3 Playboy) spanning "buS"+"A3"2NX, causing the wrong
ClassCode/Typerole to be derived downstream.

Add a word-boundary-aware ContainsToken check (match must not be
adjacent to another letter/digit) and stop stripping spaces, so only
genuine standalone tokens match.

Pr 123 model matching

Update Docker user in workflow

…hing sim-less hubs

A headless CONSOLE hub with no local simulator connection never
applied received FloatVariables/String8Variables network messages to
variableSet, because Sim.UpdateAircraft gated the update behind
`Connected && Created` - permanently false with no sim attached. The
guard was redundant: VariableMgr.Set.UpdateFloats/UpdateString8 already
branch internally on the same connected/simId check and fall back to
storing the value directly when there's no live sim to push into, same
as the integer overload has always done unconditionally. This is what
broke when PR tuduce#120 moved COM1/COM2 from an integer (BCD) to a float
(MHz) variable for 8.33 kHz support - it moved the data from the
always-applied integer path onto this dormant, over-guarded float
path.

Also consolidates the duplicated float-with-legacy-BCD-fallback
frequency read logic (AircraftForm, WebSocketServer, WebhookService,
Whazzup) into a single VariableMgr.Set.GetFrequency helper, so this
class of "fixed in one place, missed the others" bug can't recur.

Temporary debug build: logs the outgoing float variable dump on
broadcast (Sim.cs), and on receive, traces exactly what happens to the
two COM frequency vuids in VariableMgr.Set.UpdateFloats (definition
lookup result, UserAircraft/injected/definition.injected/pilot flags,
simId, Connected) to pin down why squawk (int) updates on a sim-less
hub while COM frequency (float) doesn't, despite an apparently
identical gate condition.

The previous debug commit used main.MonitorVariables, which is gated
behind main.monitor.variables - a flag only ever toggled via a GUI
checkbox (MonitorForm.cs) that doesn't exist in the CONSOLE build.
There's no CLI flag for it, so on a CONSOLE hub it's permanently false
and the RECEIVE FLOAT line never printed, regardless of what was
actually happening on receive. Switched to main.monitor.Write gated by
main.settingsWebSocketLog (--websocketlog), matching how the existing
[WS-DBG] and webhook log lines already work.

Confirmed via live diagnostic logging: VariableMgr.Set.UpdateInteger/
UpdateFloats/UpdateString8 gate incoming network variable updates
behind "UserAircraft && (...) || injected && definition.injected".
On a headless hub with no local simulator, UserAircraft is always
false, so an update only survives if its definition line in
Plane.txt/Rotorcraft.txt is tagged INJECTED - a tag meant to mark
variables that should be pushed into a local SimConnect AI object
for visual animation (gear, lights, flaps), not whether a value is
safe to remember for relay/webhook purposes. COM frequency, squawk,
NAV radios etc. aren't tagged INJECTED, so every update for them was
silently discarded on a sim-less hub regardless of the earlier
Connected/Created fix.

Skip this gate entirely when there's no live sim connection to push
into, falling through to the existing "just store the value" path.
Behavior with a sim connected is unchanged.

Also removes the temporary RECEIVE FLOAT diagnostic logging used to
confirm this.