Follow Printer Light cannot be enabled: the setting is reported but never parsed

**Firmware:** v1.0.1 (also present in v1.0.0)
**Hardware:** Panda RGB Controller paired with an H2C

## Summary

`Follow Printer Light` cannot be turned on by any client. The device reports a `follow`
field in its state but appears to have no handler that reads it, and the control was
never placed in the web interface, so there is no way to reach it at all.

## What happens

Sending the message the web interface's own `checkbox_follow_clicked()` would send:

```json
{"settings": {"rgb_info_mode": 5, "follow": 1}}
```

The device accepts the frame and `settings.follow` remains `0` on the next connect. I
tried it as a JSON number and as a JSON string, with and without the `rgb_info_mode`
field, and in all six light effects. The same message shape carrying `on` instead of
`follow` applies immediately, so the WebSocket path itself is fine.

## Why the control cannot be found in the web interface

In the page embedded in the firmware:

- there is no element with id `id_btn_rgb_follow`, so the toggle is never rendered
- `rgb_follow_mode` and `note_follow_printer` are defined in the translation table and
used in no markup
- `rgb_is_follow_switch()` and `checkbox_follow_clicked()` are both defined and never
called

For comparison, `id_btn_rgb_on` and `id_btn_rgb_warning_override` do exist as elements
and their controls work.

The embedded page is byte identical between the v1.0.0 and v1.0.1 images published here,
166,038 bytes in both, so this is unchanged since the first release.

## Reproduction

1. Connect to `ws:///ws` with any WebSocket client
2. Note `settings.follow` in the state pushed on connect
3. Send `{"settings":{"rgb_info_mode":,"follow":1}}`
4. Reconnect and read the state again: `follow` is unchanged

## Related work already in this repository

PR #2 patches the neighbouring behaviour in the same area, `get_display_state()` in
`app_rgb.c`, so somebody has already mapped this part of the image. I verified the two
offsets that PR cites against the official v1.0.1 binary and both match: `0x4a9f6` holds
`01 45`, a `c.li a0, 0`, immediately followed by `82 80 11 45 82 80`, which is the return
0 path and a return 1 path, and the two breathing constants at `0x63f8` and `0x63fc` are
`-1.0` and `+1.0` float32. Mentioning it because whoever picks this up may find that
mapping useful, and because a `follow` handler would sit close by.

## Suggested fix

Parse `follow` in the settings handler, and add the toggle to the Control Panel card next
to the ON/OFF switch, which is where the unused `rgb_follow_mode` label suggests it was
intended.

## Unrelated observation, since it is a one line fix

`rgb_info_brightness` and `rgb_info_speed` are accepted only when the value is a JSON
string. A JSON number is silently ignored:

```json
{"settings": {"rgb_info_brightness": 90}} ignored, stored value unchanged
{"settings": {"rgb_info_brightness": "90"}} applied
```

Every other numeric field in the protocol accepts a number, which makes these two
surprising for anyone writing a client. The web interface always sends strings because it
passes an HTML slider's `.value` through unchanged, so the inconsistency is invisible from
the browser. Accepting either form would help.

Start with app_rgb.c around get_display_state() and locate the settings handler that processes the reported settings fields. Then inspect the embedded Control Panel markup and the existing follow-related functions. Done means follow can be set and persists after reconnect, the toggle is rendered beside the other controls, and the accepted brightness and speed value forms behave consistently.

Written by the indexing model from the issue text.