fix: guard an out-of-range layout_id, show a not-responding badge

[ArthurGibert]

Two small, related fixes for how the configurator and firmware handle an app
that doesn't answer a parameter request — one a crash, one a silent gap in
the UI.

Firmware: out-of-range layout_id crash

GetAppParams/SetAppParams indexed APP_PARAM_SIGNALS[layout_id as usize]
straight from the client-supplied message with no bounds check. Every other
caller gets layout_id from a real Layout, so it's always valid; these two
read it off the wire raw. A malformed or out-of-range request (layout_id >= 16) indexes the fixed 16-element array out of bounds and panics, halting the
whole device. Found while reviewing #688/#690/#691's neighborhood, not
triggered by anything currently in the catalogue.

Now answers nothing for an out-of-range id, the same as an app that never
replies — no crash, no behavior change for any valid request.

Configurator: a silent app used to just vanish from the Device tab

An app with declared params that never answers a request (no param handler,
wedged, mid-quarantine) had no entry in the Device tab at all — indistinguishable
from it not being in the layout. Now it still gets a card, with a "Not
responding" badge next to its name and a short explanation instead of a
parameter form (rendering one with empty or default values would look real
and risk overwriting the app's actual state on save).

Verified

• Gates green: fmt, firmware clippy, configurator lint + build.
• Not hardware-verified — the malformed-request path needs a crafted SysEx
  frame to trigger (nothing in the catalogue sends an out-of-range
  layout_id), and the "not responding" badge needs an app with no param
  handler in a layout, which the catalogue no longer has now that Manifold
  and Ripppple both have one (fix: announce only the apps that answered in the param batch #690, chore(release): faderpunk v0.1.0 #60). Both are small, reviewable by
  inspection.

🤖 Generated with Claude Code