Decode MBT messages / track control channel utilization in addition to msg/s

[taclane]

• Multi-block (MBT) trunking messages on the control channel were dropped. This is likely what's going on with the Harris site reported on Discord; if this information is being carried by a multi-block message, the lack of it could cause cascading failures. MBT grants, patch grants, unit-to-unit, affiliations and registrations are converted to their TSBK form and handled the same way. This mirrors previous behavior regarding these messages in trunk-recorder.

• Added control channel airtime next to msg/s on the Decode page. Messages per second isn't comparable between systems: one MBT can take the airtime of 2–3 TSBKs, and some sites further pad with TDUs. Airtime is the share of the channel actually decoded.

• TRP_CC_PROFILE=1 logs a per-minute breakdown of control channel frames (kind, rate, spacing, airtime, a sample of each MBT). Off by default.

Testing

Ran it on production against two CLMRN sites. CLMRN-I went from ~12 to ~24 msg/s, and both sites read 96–98% airtime. CLMRN-G (TSBK only) is unchanged.

[taclane]

Added control channel coverage as a tile on the Decode page and a chart on each P25 system's page.

It's a timing-based estimate of how much of the CC decoded; and comparable across systems where msg/s often isn't.

Also fixed the schema check that failed CI earlier.

[robotastic]

Great - catch. Gonna have Claude research a bit more and then merge this in

[taclane]

Great - catch. Gonna have Claude research a bit more and then merge this in

It seems like it's more than just harris systems as well. It's probably at the root of most of the reported problems in Discord where users aren't pulling a WACN/SYS for their system or otherwise cant decode anything.

Trunk Recorder used to decode a handful of "important" MBT messages and send them downstream if encountered. This pretty much brings it back to that level of functionality for harris and certain other P2 systems.