Add Inhero MR2 board variant (nRF52840/RAK4630 solar repeater)

[liekmarflow]

Closes #3130. Builds on #3131 (board hooks) — the diff shows that commit as
well until it lands; I will rebase and mark this ready once it does.

Adds the Inhero MR2, a purpose-built solar repeater platform that is in
production and shipping:
https://shop.inhero.de/en/products/inhero-mr-2-solar-mesh-repeater-board-rak4630-sx1262-mppt-red-ce-gepruft
I am the hardware manufacturer; I can test changes on real hardware and am
happy to be tagged on anything affecting this variant.

Where the code lives: the MR2's logic sits entirely in the variant. This
PR's own commit is 32 new files — boards/inhero_mr2.json plus everything
under variants/inhero_mr2/ — and leaves every existing file untouched. Of
its 6496 lines, 454 are board and build definitions; the rest is device code:
BQ25798 and INA228 drivers, battery chemistry profiles, JEITA charge control,
SOC accounting, low-voltage sleep. The core changes visible in the diff are
#3131's two no-op hooks; the board.* CLI rides on the existing
MainBoard::handleCommand() hook.

Hardware: RAK4630 (nRF52840 + SX1262), BQ25798 buck/boost charger with
universal 3.6-24 V solar input and MPPT, INA228 coulomb counter, RV-3028
RTC, BME280, 45 x 40 mm, CE-certified (RED 2014/53/EU).

What the variant provides:

• Battery chemistry profiles (Li-ion, LiFePO4, LTO, Na-ion) with JEITA
  temperature-controlled charging and per-chemistry low-voltage thresholds,
  all configurable at runtime over the CLI and persisted across reboots
• An operator-controlled override that keeps charging below the JEITA cold
  limit for frost-period solar sites, bounded by a static gate of 0.05C of
  the stated battery capacity (set board.jeitaignore, off by default)
• SOC tracking via hardware coulomb counting, 7-day energy statistics and
  a time-to-live prediction
• Low-voltage system sleep (<500 uA) with RTC wakeup and autonomous recovery
• board.* CLI namespace for configuration and diagnostics; the full
  documentation set (EN/DE) is maintained in the vendor fork, linked from
  variants/inhero_mr2/README.md
• Build environments: Inhero_MR2_repeater,
  Inhero_MR2_repeater_bridge_rs232, Inhero_MR2_sensor

Field record: I run a part of the MeshCore repeater infrastructure for a
region in Saxony, Germany — hilltop and mining-tower sites with links from
70 km to over 100 km, plus a number of small birdhouse-style nodes. Almost
all of them are MR2 by now, so this board already carries a significant share
of the MeshCore traffic here.

A representative small node, read out of the MeshCore app on 2026-08-19:
123 days of continuous uptime on solar, 701,487 packets sent and 2,003,527
received, 4 d 20 h of TX airtime (596 ms per packet, one packet every 15 s
on average), 35 % forward ratio, battery still at 100 %. Measured
consumption in real repeater operation is ~0.98 Wh/day.

Another unit ran 140 days before it surfaced a charge-accounting bug; that
bug is reproduced, verified on two battery chemistries, and fixed in this
branch.

Background on the design and the field failures that drove it:
https://shop.inhero.de/en/blogs/news/warum-es-das-mr2-gibt

Build and docs: all three variant environments build green, as does
RAK_4631_repeater from the PR build-check matrix. The documentation set was
verified against the code (CLI replies, thresholds, register values) before
submission.

Transparency: this variant was developed with AI assistance under my
continuous engineering direction and review, followed by a full
pre-submission review pass. Stated upfront in line with this project's
position on code provenance. I manufacture this board and run it in the
field; I will keep the variant building and correct, and I am happy to be
tagged on anything that touches it.