Add Lierda AM36 Pico (L-LRMAM36-FANN4-PK02) variant — ESP32-S3 + Semtech LR2021

[omegaconjecture]

Depends on #2944 (adds the CustomLR2021 / CustomLR2021Wrapper radio
classes). CI will fail on dev until that PR merges — opening as a draft and
will mark ready for review once it lands. The variant builds cleanly against
the #2944 branch today.

Adds a variant for the Lierda AM36 Pico evaluation board
(L-LRMAM36-FANN4-PK02). The board carries Lierda's L-LRMAM36-FANN4 module:
an ESP32-S3 (8 MB flash / 8 MB PSRAM) paired with a Semtech LR2021
Gen-4 LoRa transceiver. As far as I can tell this is the first ESP32-S3 +
LR2021 target in MeshCore.

Headline test result: confirmed LR2021 ↔ SX1262 interoperability on a live
mesh — messages received from six distinct third-party senders at up to
9 hops, with full path reconstruction. Details below.

Environments added

• Lierda_AM36_Pico_companion_radio_usb
• Lierda_AM36_Pico_companion_radio_ble
• Lierda_AM36_Pico_repeater

Names follow the existing suffix convention, so build.sh target discovery
picks them up with no changes needed to the release workflows.

Pin map and provenance

Signal	ESP32-S3 GPIO
LR2021 SPI SCK	40
LR2021 SPI MOSI	41
LR2021 SPI MISO	42
LR2021 NSS	39
LR2021 NRST	38
LR2021 BUSY	17
LR2021 IRQ	21 — routed from LR2021 DIO7

Values are taken from Lierda's own ESP-IDF driver,
lierda-iot/esp32_lora_driver,
specifically the default N if LIERDA_BOARD_LRMAM36_FANN4 entries in its
Kconfig (LR2021_SPI_CLK, LR2021_SPI_MOSI, LR2021_SPI_MISO,
LR2021_NSS_GPIO, LR2021_NRST_GPIO, LR2021_BUSY_GPIO, LR20XX_DIO7_GPIO),
cross-checked against the board schematic shipped in
lierda-iot/esp32_lora_samples
under docs/L-LRMAM36-FANN4-PK02_SCH_V01.pdf.

Important difference from the Seeed Wio-LR2021 kit in #2944: the host IRQ on
this module comes from the LR2021's DIO7, not DIO8. The variant therefore
sets -D LR2021_IRQ_DIO=7. Without this override the radio initialises and
transmits, but send-completion and receive interrupts never fire.

Board specifics

• No status LED. The board's only LED is a hardwired 3V3 power indicator
  (V3P3 → 620R → LED1 → GND on the schematic), so PIN_STATUS_LED is
  deliberately not defined.
• KEY button left disabled. The schematic net label suggests GPIO4, but I
  haven't traced it on hardware, so PIN_USER_BTN is commented out with a note
  rather than shipped unverified. Happy to enable it in a follow-up.
• PSRAM not enabled — MeshCore doesn't need it, and it avoids octal-PSRAM
  boot-loop pitfalls on the S3.
• SPI lands on GPIO39–42, which are the S3's JTAG pins. Harmless here since
  flashing and debug both go over native USB-JTAG.
• Two USB-C ports. The one silkscreened USB is the ESP32-S3's native USB
  and is what esptool talks to; UART goes to an on-board CP2105 bridge and is
  not used for flashing. Noted in the variant README since it's an easy trap.
• Radio parameters are left at MeshCore's inherited defaults — no region
  hardcoding — since the companion app sets and persists them at runtime.

Hardware testing

Tested on a physical board, not just built.

Test setup

• DUT: Lierda AM36 Pico, Lierda_AM36_Pico_companion_radio_ble build
• Peer: Heltec Tracker v2 running MeshCore (heltec_tracker_v2,
  CustomSX1262) — so this exercises LR2021 ↔ SX1262 interop
• Antennas: muzi ᴡᴏʀᴋꜱ 17 cm whip
  (SMA male, manufacturer-measured SWR 1.3) on both nodes
• Radio params: 927.875 MHz / BW 62.5 kHz / SF9 / CR7, LORA_TX_POWER=22
• Client: MeshCore iOS app over BLE
• Base: v1.16.0-era dev + Kit lr2021 #2944, RadioLib 7.7.1, espressif32 @ 6.11.0

Transmit

• Radio init clean; noise floor sampling steady at ~−119/−120 dBm with dips to
  −108…−115 dBm on channel activity (i.e. real ADC reads, not a stuck register)
• Flood (type=4, route=F) and direct (type=9, route=D) TX both confirmed,
  logged via the success path of isSendComplete() — i.e. interrupt-driven
  completion, with no outbound packed send timed out warnings. This is what
  validates the DIO7 IRQ routing.
• LORA_TX_POWER=22 exercised on air with no instability observed

Receive

• Two-way messaging with the SX1262 peer: channel message sent from the
  AM36 Pico was received by the Heltec Tracker v2, and the reply was received
  back on the AM36 Pico at SNR 3.25 dB. Some traffic between the two nodes
  routed through repeaters that I operate.
• Channel messages received from six distinct third-party senders over a
  ~1 hour window — operators and hardware I have no involvement with.
• Multi-hop reception confirmed across a wide range of path lengths: packets
  decoded at 3, 4, 5, 6, 7 and 9 hops, plus one direct (0-hop) reception.
• Path reconstruction verified: the app resolved complete repeater chains
  for received messages (a 4-hop path across four intermediate repeaters and a
  5-hop path across five, at 2 bytes per hop), confirming the radio works
  correctly with MeshCore's path/routing handling and not just point-to-point
  links.
• Discovered and measured a repeater I do not operate at
  ↑11.5 dB / ↓13.0 dB — that same repeater subsequently appeared as the
  final hop in a received message's path. Own transmissions were also seen
  returned as repeats ("Heard 2 Repeats").

Companion / host interface

• BLE pairing and companion protocol confirmed with the iOS app
  (App meshcore-flutter connected); device reports as Lierda AM36 Pico
• Radio parameter changes pushed from the app applied and persisted correctly
  (CMD_SET_RADIO_PARAMS accepted)

Not covered

• KEY button GPIO (see above)
• Repeater and USB-companion environments compile but were not field-tested;
  only the BLE companion build was run on air
• FLRC and the LR2021's other Gen-4 modes — plain LoRa only, matching current
  MeshCore behaviour
• No range testing; all RF testing was short-range, though received traffic
  traversed multi-hop paths across the local mesh