feat: fit the message cap, the pools, the ring and the stacks to this device - #66

... device
Every collaborator is in place, so the compile-time sizes come down to what the
device uses.
 Flash +13,788 B (unchanged)
 RAM +36,048 B (-3,488)
 Log stack +600 B (-80)
 Service +3,688 B (-80)
The message cap comes first: the ring, the store's record buffer and the
formatter frame on both task stacks all follow it. The worst case measured here
is 345 octets — four SD-ELEMENTs with both counters at full 32-bit width and both
addresses at fifteen characters, plus a short message — and the cap is set to 400
to allow for longer messages on this device.
The ring then drops from eight records to four, the store holding the backlog.
Three pool tunables come down to one, the library's defaults being sized for a
device running several transports at once. The stacks go last, at twice their
measured high-water marks rounded up to a whole configMINIMAL_STACK_SIZE.
The overrides arrive through SOLIDSYSLOG_USER_TUNABLES_FILE, which the library
carries on an INTERFACE target, so Core, the platform packs and this application
compile against the same values. They change struct sizes, and a build where only
some translation units saw them would disagree about how big those structs are.
Nothing here changes what the device does or what protection it is under.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>