[Bug]: Interactive Labeler hotkeys are silently dead when focus is on a class radio or a toggle switch

[airshiner]

Summary

The Interactive Labeler's own on-screen help advertises:

Click a building to label it · right-click to clear · Ctrl+drag to box-label · 1/2/3 set class · P toggle view · Space show/hide footprints · with swipe on, A/S/D snap divider

Every one of these keys stops working — silently, with no visual feedback — whenever keyboard focus is on one of the side-panel Fluent controls. Clicking the Set class radio with the mouse is the most natural way to change class, and it parks focus exactly where the hotkeys die.

Steps to reproduce

1. Open the Interactive Labeler on any layer with an embedding model.
2. Click the Set class radio in the side panel with the mouse (do not click the map afterwards).
3. Press 2.

Expected: class switches to Damaged.
Actual: nothing happens. The radio stays on Intact. No error, no visual response.

Measurement

Same page, same model, varying only which element holds focus. Pressing 2 (should select Damaged):

Focus is on	document.activeElement	2 selects Damaged?
Set class radio	radio-r5 (role=radio)	No
Footprints switch	switch-r9 (role=switch)	No
Advanced button	BUTTON	Yes
Map canvas	CANVAS	Yes
Nothing (document.body)	BODY	Yes

With focus on the class radio, P (toggle predicted view) and 3 (Cloudy) are also dead. With focus returned to the canvas, P works immediately. So it is not one key — it is the whole hotkey set.

Likely cause: Fluent UI's Radio / Switch consume character and digit keydowns for roving focus and type-ahead, and stop propagation before the labeler's global handler sees them.

Impact

This does not merely fail to act — it silently writes the wrong label. Real sequence from an end-to-end walkthrough:

1. Clicked a side-panel control (focus parked there).
2. Pressed 2, intending Damaged. Class silently stayed Intact. No feedback.
3. Labelled 30 buildings in a confirmed total-loss block.
4. All 30 were written as Intact — the exact opposite of intent.

The label count readout does update, so it looks like it is working. The error is only visible if you happen to read the small radio state. For a new user following the on-screen help, this is a trap that poisons the training set and degrades every downstream prediction round.

Suggested fix

Bind the hotkey handler at the document/container level in the capture phase, or return focus to the map after any side-panel control is actuated. At minimum, make the active class visually unmissable so a failed class switch is obvious before the user starts clicking.

Not a duplicate of

• [Feature]: Document (and maybe standardize) hotkeys across map views #47 — a feature request to document and standardise hotkeys across map views. It does not describe a broken hotkey.
• [Bug]: Building footprints stop accepting clicks above ~zoom 18 #115 — mouse clicks being rejected above zoom 18. This is a distinct keyboard-focus defect.