LoRa: DMA-based driver to replace blocking SPI.

[MasterUser43]

Description

Replaces the blocking/interrupt-driven SPI LoRa driver with a DMA implementation for lora.c/lora.h, & removing lora_async.c (whose logic was folded into lora.c for consistency).

Adds LORA_IDLE_MODE as a per-board compile-time macro (STANDBY for FLIGHT_COMPUTER, RX_CONTINUOUS for GROUND_STATION/A0010).

Diff is scoped entirely to lora/ — no changes outside the LoRa driver w/ this specific PR.

Issue Link

Closes #20 (LoRa: Switch to DMA)

Testing

• Passes existing automated tests
• Automated tests modified
• Manual test performed

Builds clean (make clean && make in app/rev2) & flashes/verifies successfully to an A0002 rev2 board (STM32H750VBT6). Preset upload over SDECv2 confirmed working (feature bitmask + LoRa params both land).

TX itself is not yet verified. This PR should not be pushed until Tx at minimum is verified with a board that has an operational LoRa chip. Will re-test and update this PR once actually testing. Artifacts of testing are present in the build and will be removed once testing is settled.

AI Disclosure (Required)

• Was an AI agent used to synthesize a significant portion of the submitted code?
• Do you understand that you are responsible for your contributions, regardless of whether they are generated or hand-written?

Other

PR is meant to be left as open.

Reviewer Checklist

Standards

• Follows FCF Architectural Standards
• Follows SDR Coding Standards
• Code complexity/function Size is minimized
• Code is testable
• Code is readable and commented properly
• License terms are respected

Accuracy

• Code implements the correct requirement (a.k.a. does the right thing)
• Code is logically correct (a.k.a. does the thing right)

Error Handling

• Potentially unsafe functions return a status code
• Error returns properly handled
• Fail-fast errors are only thrown when unsafe to continue software execution
• Debug errors are thrown for exceptions where execution should still continue (to be noticed during development)

Memory

• Stack allocated memory is scoped correctly
• Heap allocated memory is not used
• Statically/Globally allocated memory is minimized except when necessary
• Pointers are used correctly
• Concurrent access has been considered (especially by/from interrupt service routines)

Performance

• Rate limiters are respected
• Busy waiting is avoided in performance sensitive code
• "Delay" calls are not used in performance sensitive code
• If performance is negatively impacted, a justification is provided and the impact is quantified