Work queue stacks are carved from the same allocator pool as the heap on
NuttX, so an over-reserved queue stack costs the board free memory directly.
This board runs out of heap before MAVLink can start (#28109).

Measured at default sizes with CONFIG_STACK_COLORATION=y, reading StackUsed
from top and /proc/<pid>/stack:

  queue         default   peak   set to   margin
  lp_default       3472   1412     2400     1.70x
  hp_default       2776   1104     2300     2.08x
  I2C1             2312    840     1900     2.26x

Effect: 2040 B returned to the heap.

Verified after trimming, on the resulting firmware rather than by calculation:

  queue         trimmed   peak   margin
  lp_default       2376   1388    1.71x
  hp_default       2272   1104    2.06x
  I2C1             1872    840    2.23x

lp_default's peak appears only after provoking the parameter autosave, which
runs on that queue and writes through to storage. Idle it reads 1100 B, so the
deep path has to be triggered deliberately: change a parameter to a genuinely
different value, since PX4 only saves when the value changed, then re-read
StackUsed. On a board too full to run top this is readable with
cat /proc/<pid>/stack, which reports the same up_check_tcbstack() figure.

The remaining queues are left alone because they have no slack: rate_ctrl
1.28x, SPI1 1.42x, INS0 1.56x, nav_and_controllers 1.69x. SPI2 looks generous
at 3.02x but CONFIG_WQ_SPI_STACKSIZE sizes every SPI queue, so its headroom
cannot be taken without starving SPI1.

INS0 is why these are measured rather than estimated: its peak is 1180 B with
ekf2 stopped and 3828 B once ekf2 runs in that queue.

Four of the seven ports carry hand-inflated buffers while every other port on
the board uses 300. They are static allocations, so they come straight off the
heap arena, on a board that runs out of heap before MAVLink can start (#28109).

  USART1 TX  2500 -> 600   ESP8266 header, usually unpopulated
  USART2 TX  1100 -> 600   TELEM1
  USART3 RX  1200 -> 600   TELEM2
  USART3 TX   900 -> 600

Effect: 3328 B of static RAM returned, flash unchanged. Measured with the
NuttX submodule cleaned, since it builds in-tree and does not rebuild on a
config change, and verified in the ELF with nm.

No functionality is removed. What is given up is burst headroom: MAVLink defers
when a TX buffer is full, so a stream is throttled rather than lost, and 600 B
is still 83 ms at 57600 baud. Both telemetry ports have hardware flow control
and RX DMA, so a full RX ring asserts RTS instead of dropping bytes.

This cannot affect the failure in #28109, which is on USB, a CDCACM link with
its own separate buffers.

CONFIG_FS_PROCFS_MAX_TASKS sizes system_load.tasks[], the per-task reporting
table behind top, /proc and the cpuload accounting. NuttX defaults it to 128
and this board never overrode it, so 128 slots at 24 B each are reserved for
the life of the board. It runs 25 tasks, counted with ls /proc.

Effect: system_load 3096 -> 1560 B, so 1536 B of static RAM returned to the
heap arena.

The second effect matters more on this board. Every NSH builtin needs a 4096 B
task spawn, and before this the largest free block with a ground station
attached was 3760 B, so no console command would run at all: param and top both
failed with "command not found", which is ENOMEM in disguise. With this the
largest block reaches 4416 B and the console works.

64 leaves 2.56x headroom over the live count, enough for the transient tasks a
calibration or parameter save adds. If the limit were ever exceeded, top and
procfs would list fewer tasks and a task's CPU time would go unaccounted;
nothing else is affected.

The verbose estimator uORB nodes cost heap this board does not have. Measured
on hardware with EKF2 running and two MAVLink instances up: 7440 B free at 0
against 3696 B at 1.

Effect: 3744 B returned. On this board that is not optional headroom. With the
receive stack fix alone and this parameter at its upstream default, the board
comes up and streams telemetry but answers no request at all, no PARAM_VALUE
and no COMMAND_ACK, and a ground station hangs requesting capabilities.

Cost: the default logging profile picks up estimator* topics by name prefix at
2 Hz via add_optional_topic_multi, which only logs advertised topics, so turning
it off removes innovations, variances, test ratios, states, the aid_src_* set and
the bias topics, and Flight Review's innovation plots go empty on this board.
estimator_status still carries the filtered test ratios, filter fault flags,
reset counters and pre_flt_fail_innov_*, and replay still works because
SDLOG_PROFILE bit 1 logs EKF2's inputs.

Applied with param set-default so an operator can opt back in. rcS sources
rc.board_defaults at line 280 and starts ekf2 at 437, and EKF2 reads the
parameter in its constructor, so the default lands in time. Note a board with
this parameter explicitly saved keeps its saved value.

…mator and SIH

This board is at 94.7% flash on main and out of heap before MAVLink starts
(#28109), so it needs static RAM back, not only flash.

Measured by building fmu-v4 with and without each:

  UAVCAN               flash -147276 B   static RAM -3520 B
  uxrce_dds_client     flash  -59508 B   static RAM   -64 B

Effect: 3652 B of static RAM and 207 kB of flash returned.

UAVCAN is the only module here that returns meaningful RAM, and it is paid even
though the driver never starts, since UAVCAN_ENABLE defaults to 0. For contrast,
dropping five other modules including attitude_estimator_q and
local_position_estimator returned 128 B, so module removal is otherwise a flash
lever only. The UAVCAN driver costing 3.5 kB of .bss wherever it is compiled in
and not started is worth fixing properly for every constrained board.

This is a trade and is offered as one. A Pixracer with a DroneCAN GPS or CAN ESCs
loses them and must set CONFIG_DRIVERS_UAVCAN=y in a local build.
mag_bias_estimator is likewise a deliberate feature removal: MBE_ENABLE defaults
to 1 and rcS starts it, so pre-takeoff continuous magnetometer calibration goes
away on this board. SIH never runs on hardware and uxrce_dds_client only starts
when UXRCE_DDS_CFG points at a port, so neither holds heap today.