feat(channels): mark channel messages sent without a region scope (like the 1-byte path-hash recommendation) #480

Problem

When a channel message carries a region scope, the Channels meta line shows scope: #dk · area: …. When it carries none, the line shows nothing, so users do not notice that the message was sent without a scope. This follows the same idea as the 1-byte path-hash recommendation (#353 / #356).

Why it matters (firmware)

• Companion. examples/companion_radio/MyMesh.cpp sendFloodScoped(GroupChannel…), around line 514: a channel message is sent with the app's default flood scope. If none is set, or the app explicitly requests it, the message is sent unscoped as a plain FLOOD. There is no per-channel scope yet; the firmware has a TODO for it.
• Repeaters. flood.max.unscoped caps the hops of unscoped floods. The default is 64, but docs/cli_commands.md recommends a low value such as 3, or region denyf *, to stop noisy neighbours. With 0, unscoped packets are dropped at hop 0 (comment in simple_repeater/MyMesh.cpp sendFloodReply).
• So an unscoped message floods outside the sender's region, and repeaters that limit unscoped traffic may stop it.

Prevalence. On staging, 2026-10-08 … 2026-10-13, 64.5% of 10,386 GRP_TXT transmissions were unscoped (FLOOD) and 35.5% were scoped (TRANSPORT_FLOOD). The marker therefore appears on most messages and must stay compact.

Design (owner-approved)

1. Channels message meta line. Where a scoped message shows scope: #dk, an unscoped message shows ⚠ no scope in the same amber recommendation style as the 1-byte path-hash warning (--path-hash-warn / var(--warning) and the Phosphor warning icon, not error red). There is no extra pill and nothing new on scoped messages.
   • Tooltip / accessible text: "Sent without a scope. The message floods outside your region, and repeaters that limit unscoped traffic (flood.max.unscoped / region denyf) may stop it. Recommended: set a default scope (region) in the companion app."
   • Do not claim that a low heard-count is caused by the missing scope. Only state the firmware behaviour.
2. Packet detail. Add a Scope row with the same marker and explanation for unscoped GRP_TXT/GRP_DATA. Keep the existing display for scoped packets.
3. Detection. Use the transmission's route type. FLOOD means unscoped; TRANSPORT_FLOOD means scoped, whether the name is known or not. Do not use scope_name alone: a scoped transmission with an unknown name has scope_name = '', and that is NOT "no scope". DIRECT routes are not flood scope and get no marker. Check the actual API response shapes first (AGENTS.md rule 4) for the channel messages API and the packet detail.
4. DRY. Add one shared helper, for example in app.js next to isPathHashSizeWarn, that decides "unscoped flood" from a route type. Reuse it in both places.

Tests

• Unit tests for the helper: FLOOD, TRANSPORT_FLOOD with a name, TRANSPORT_FLOOD with an empty name, DIRECT, TRANSPORT_DIRECT, missing or invalid values.
• Frontend render tests for the channel meta line and the packet detail row. A mutant that marks TRANSPORT_FLOOD as unscoped must fail.
• An E2E that checks the marker on an unscoped fixture message and its absence on a scoped one.
• WCAG AA contrast in both themes, as feat(ui): warn on 1-byte path hash in channels, packet detail and node badge (#353) #356 measured.

Acceptance criteria

Unscoped channel messages show the compact amber no scope marker and the explanation. Scoped messages are unchanged. No per-message API calls are added.