Pt97 compliance, Add strict gatekeeper mode for Meshtastic/MeshCore ingress

[mathisono]

Summary

This PR adds an optional Strict Gatekeeper mode for Raven bridge deployments that forward Meshtastic or MeshCore text traffic into AREDN.

The goal is to make the bridge fail closed for common amateur-radio compliance risks when crossing from an unlicensed mesh into an AREDN / amateur-radio network.

What changed

• Adds a new gatekeeper.uc policy module.
• Adds strict_gatekeeper configuration support:

{
  "strict_gatekeeper": {
    "enabled": true,
    "gateway_callsign": "W6XYZ",
    "allowed_callsigns": ["KN6PLV", "KJ6DZB"]
  }
}

• Validates sender identity by extracting a US-style callsign token from node names.
• Supports an optional allowed_callsigns whitelist.
• Drops encrypted Meshtastic packets before the legacy decrypt path is reached.
• Drops non-text Meshtastic/MeshCore bridge ingress in strict mode.
• Rewrites accepted bridged text to originate from the gateway node instead of spoofing the remote Meshtastic/MeshCore sender.
• Prefixes bridged text as:

[SENDER via GATEWAY] message

For example:

[KN6PLV via W6XYZ] Hello

• Adds a router-level defense-in-depth filter so future transport changes do not accidentally enqueue non-compliant bridge ingress.
• Adds STRICT_GATEKEEPER.md documenting configuration, behavior, and operational caveats.
• Links the new guide from the README.

Rationale

Meshtastic and MeshCore are useful companion meshes, but AREDN runs in a licensed amateur-radio environment where cleartext operation, station identification, and operator control matter.

The previous behavior allowed bridge traffic to be forwarded too openly. This PR introduces an opt-in mode that:

1. rejects encrypted Meshtastic ingress before decryption;
2. requires the apparent sender to match a callsign-shaped identity and optional whitelist;
3. injects the final AREDN message as the gateway station, with the remote operator identified in the message body.

This preserves existing non-strict behavior by default while providing a safer operating mode for regulated deployments.

Notes and caveats

Strict Gatekeeper mode is not cryptographic identity proof. Meshtastic and MeshCore names are user-controlled, so a node can be renamed to look like a valid callsign. For real deployments, operators should use allowed_callsigns, and a later hardening step should bind allowed operators to stable Meshtastic node IDs or MeshCore public keys.

The callsign validator intentionally matches a simple US amateur callsign form: one or two letters, one numeral, and one to three letters. This will reject international callsigns or unusual/special-event formats that do not contain an extractable US-style token.

Dropped packet logging uses the existing DEBUG0 and DEBUG1 channels, so headless OpenWrt deployments should confirm service/logd capture before relying on logs for troubleshooting.

Testing

• Not yet tested on live RF hardware in this PR.

• Code was reviewed for ingress chokepoints:

  • Meshtastic encrypted packets are rejected in meshtastic.uc before decrypt branches run.
  • Meshtastic/MeshCore ingress is filtered before router queue admission.
  • Accepted text is rewritten to use the gateway node identity.

Follow-up work

MeshCore direct-message handling currently still performs protocol-level decryption inside meshcore.uc before the router-level strict filter sees the decoded text. The router filter prevents non-text or non-rewritten MeshCore ingress from entering the queue, but the strictest future improvement would be to add a MeshCore decoder-level gate similar to the Meshtastic encrypted-packet hard stop.