wio-e5-mini_repeater fails to build: unpinned ststm32 floated to 20.0.0, where 'ltoa' is no longer declared

[hoejriis]

Summary

platformio.ini leaves ststm32 unpinned. On 2026-08-31 it floated to
20.0.0, whose newlib no longer declares ltoa — a non-standard GNU
extension — and wio-e5-mini_repeater stops compiling with no code change
responsible:

src/helpers/TxtDataHelpers.cpp:105:5: error: 'ltoa' was not declared in
this scope; did you mean 'utoa'?
  105 |     ltoa(int_part, p, 10);

This is the second platform to hit the same call

PR #2025 (native Linux/Ardulinux repeater) ran into the identical problem
and works around it in TxtDataHelpers — but guarded by
ARDULINUX_PLATFORM, so the workaround does not reach any other target.
STM32 on the 20.x toolchain now needs the same thing for a different
reason.

Two independent platforms hitting one non-standard extension suggests the
guard-per-platform approach will keep accruing branches. ltoa here is
only converting a non-negative int_part to decimal, which snprintf does
portably:

p += snprintf(p, <remaining>, "%ld", (long)int_part);

That would let PR #2025 drop its guard rather than add one.

Isolation

Not assumed from the commit it first appeared on — that commit touched only
docs and unrelated environments:

1. Reproduced locally at that commit.
2. Reverted only that commit's platformio.ini change and rebuilt —
   failed identically.
3. Pinned ststm32@19.7.1 and rebuilt — succeeded in 49s.

Workaround

Pinning platformio/ststm32@19.7.1, the last of the 19.x line and what CI
was already passing with, restores the build. Reported here rather than
kept downstream since it is upstream's file and upstream's target — happy
to open a PR for the snprintf change if that is the direction you'd
prefer.