Record the squelch interrupt attempt, and why it was backed out

Scanning does work now that RSSI reports a real level -- long-press * and the
frequency steps, 6 distinct frames over 7 seconds. The S-meter still does not appear,
because ui/main.c:2370 draws it only when FUNCTION_IsRx(), which needs the chip to
report a squelch opening rather than merely a healthy RSSI.

I implemented that interrupt and backed it out. The guest kept running, but REG_0C
bit 0 remained set afterwards, meaning the firmware never collected the interrupt.
That leaves a hang armed: app/app.c:910 and :1417 spin on that bit with no timeout, so
any path reaching them with it stuck never returns. A missing S-meter is a cosmetic
gap; a latent hang is not, and shipping the second to fix the first is a bad trade.

Documented with the mechanism (REG_0C pending bit, REG_02 acknowledge-then-read,
sqlFound at bit 3), the reason it failed, and the check that says a retry is correct:
REG_0C reading 0 afterwards, which tools/test_bk4819.py already asserts. The next
person should find out why the flag was not collected rather than raise it at a
different moment and hope.

AGENTS.md

@@ -459,6 +459,29 @@ Two constraints are not negotiable, both from untimed spin loops in the firmware
   measuring. Not hypothetical: the first test run decoded 48 registers correctly and
   still reported RSSI as 0 for precisely this reason.
 
+### The squelch interrupt: attempted, backed out
+
+Scanning works — long-press `*` and the frequency really does step, 6 distinct frames
+over 7 seconds — but the S-meter never appears, because `ui/main.c:2370` only draws it
+when `FUNCTION_IsRx()`, and that needs `gCurrentFunction` to be in a receiving state.
+Reaching it means the chip reporting a squelch opening, not just a healthy RSSI.
+
+The mechanism is clear enough: `REG_0C` bit 0 says an interrupt is pending, the
+firmware writes `REG_02` to acknowledge and reads it back for the flags, and
+`sqlFound` is bit 3 (the bitfield is spelled out at `app/app.c:915`).
+
+I implemented it — raise `sqlFound` once when the firmware enables interrupts — and
+**backed it out**. The guest kept running, but `REG_0C` bit 0 was still set afterwards:
+the firmware had not collected the interrupt. That is a latent hang, because
+`app/app.c:910` and `:1417` spin on that bit with no timeout, so any path that reaches
+them with the bit stuck never returns. Shipping a model that leaves a hang armed is
+worse than shipping one without an S-meter.
+
+Anyone retrying should first work out *why* the flag was not collected — a gate
+upstream of the interrupt loop, or ordering against the receive state machine — rather
+than raising it at a different moment and hoping. The signal that it is right is
+`REG_0C` reading 0 afterwards, which `tools/test_bk4819.py` already asserts.
+
 **Where it stops.** This models the register interface, not the radio. It reproduces
 what the firmware *commanded* — frequency, power step, carrier keying in time — never
 the analogue result: keying envelopes, spurious emissions, sensitivity.