Channel ID hashing incorrect

[SimmerV]

Meshinfo's hashing of channel IDs is seemingly incorrect, further investigative work is being conducted currently to establish the root cause. The new deployment in Georgia highlighted many packets falling into various channel ID buckets on postgres but not being displayed correctly in the frontend chat.tsx

[SimmerV]

Root cause: chat_messages.channel_id mixes two namespaces.

MeshPacket.channel carries either an 8-bit channel hash or a channel slot index (0–7), depending on the uplinking gateway:

• mqtt.encryption_enabled = true (default) → gateway publishes the encrypted copy; field is the hash, xorHash(name) ^ xorHash(psk)
• mqtt.encryption_enabled = false → firmware already overwrote the field during decrypt (p->channel = chIndex), so the published copy carries that gateway's local slot index

Both land in the same column verbatim — mqtt.py:155 → mqtt.py:645 → postgres.py:1231 — with no discriminator.

Consequences

• The same node's traffic lands in different buckets depending on which gateway relayed it (observed: node a0352680 in bucket 8 via one gateway, bucket 0 via another).
• chat_messages is PK'd on packet id with ON CONFLICT DO NOTHING, so whichever copy arrives first decides the bucket. Assignment is an ingest race, not a property of the message.
• Bucket 0 is not legacy firmware — the field has never been an index-only value in any firmware version. It's primary channel expressed as an index, i.e. the same traffic as hash 8. Hardcoding its label to "General" (postgres.py:1232) is misleading; buckets 1–7 are worse, since gateway-local slot numbers have no consistent meaning across gateways.
• Any bucket > 7 is unambiguously a hash.

Everything needed to disambiguate is already parsed and then discarded

• is_encrypted (mqtt.py:112) — this boolean is the namespace tag; never persisted.
• ServiceEnvelope.channel_id (mqtt.py:95) — parsed, never read.
• The topic's channel-name segment — mqtt.py:151 stores the full topic, mqtt.py:157-161 parses only the last segment for the gateway id. Segment [-2] is the ground-truth channel name.

Proposed fix

1. Persist a discriminator (e.g. h:8 vs i:0), or resolve the bucket from the topic's channel name at ingest.
2. Optionally gate the brute-force decrypt on xorHash(name) ^ xorHash(psk) == mp.channel for encrypted variants. This also closes the ~0.78% garbage-parse path — Data().ParseFromString() succeeds on random bytes at that rate, and with break-on-first-success a wrong key permanently shadows the right one for that packet.

[SimmerV]

Getting close to submitting a PR for this.