revert(companion): trail buffer back to 512 points

The 1024-point trail buffer (16 KB in .bss, since ui_task is a global)
doubled the static footprint of the GPS trail for little practical gain on
a RAM-tight nRF52 build. Revert CAPACITY to 512 (8 KB) and sync the Tools
docs. Heap headroom is better spent elsewhere; in-stream simplification
already lets 512 vertices cover a long route.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

examples/companion_radio/Trail.h

@@ -8,8 +8,13 @@
 #include "GeoUtils.h"
 
 // RAM-only GPS trail ring buffer.
-// Storage cost: CAPACITY(1024) × sizeof(TrailPoint)(16 B, padded) = 16 KB,
-// always resident (UITask::_trail member). The trail survives auto-off (only
+// Storage cost: CAPACITY(512) × sizeof(TrailPoint)(16 B, padded) = 8 KB,
+// always resident in .bss (UITask::_trail, and ui_task is a global object —
+// see main.cpp). Because the nRF52 heap region starts just above .bss, every
+// byte added here is a byte taken from the heap: at 1024 points (16 KB) free
+// heap fell to ~4 KB and the input/menu path started failing its allocations
+// while the periodic redraw kept running. Keep this conservative. The trail
+// survives auto-off (only
 // the display blanks) but is lost on reboot — user explicitly snapshots to a
 // LittleFS slot before powering down to keep it.
 //
@@ -29,7 +34,7 @@ static const uint8_t TRAIL_FLAG_SEG_START = 0x01;
 
 class TrailStore {
 public:
-  static const int CAPACITY = 1024;
+  static const int CAPACITY = 512;
   // _count is serialised as uint16_t in the save header — fail the build loudly
   // if CAPACITY is ever grown past what that can hold, rather than truncating.
   static_assert(CAPACITY <= 0xFFFF, "TrailStore::CAPACITY must fit in the uint16_t save-header count");