build succeeded for firmware at 135% of flash / 2059% of RAM on an Uno #1409

fbuild links, writes a .hex, and exits 0 for an image that cannot fit the target.

Reproduce

platformio.ini:

[env:uno]
platform = atmelavr
board = uno
framework = arduino

src/main.ino — fourteen static arrays, nothing exotic:

#include <Arduino.h>
const unsigned char b0[3000] = {1};
const unsigned char b1[3000] = {2};
// ... b2 .. b13, same shape ...
void setup() {
  Serial.begin(9600);
  Serial.write(b0, 3000);
  Serial.write(b1, 3000);
  // ... one write per array, so nothing is discarded ...
}
void loop() {}

$ fbuild build -e uno --no-timestamp
Board: Arduino Uno / ATMEGA328P @ 16MHz
Memory: 31.50KB Flash, 2.00KB RAM
Toolchain: avr-gcc 7.3.0
Compiled 1/1 files
Linking firmware.elf
Building firmware.hex
Flash: 42.64KB / 31.50KB (135.4%)
RAM:   41.20KB / 2.00KB (2059.8%)
Artifact: ...\firmware.hex (119.95KB)
build succeeded in 1.2s (flash: 43662 bytes, ram: 42184 bytes)
$ echo $?
0

Expected

A non-zero exit and a diagnostic. arduino-cli refuses to link this.

Why it matters downstream

Our uploader treats a successful compile as proof the design fits — that is what
arduino-cli's refusal buys you, and it is the only capacity gate between a user's design
and their board. Under fbuild the compile succeeds, no linker overflow marker is printed
to pattern-match on, and the percentages are the only evidence anything is wrong. We have
since added a guard that refuses any successful build measuring over 100%, but every other
caller is presumably still trusting the exit code.

fbuild has both numbers in hand at the moment it prints them.

Environment

fbuild 2.5.21, Windows 11. Found while re-verifying our fbuild integration in
Design Studio for FastLED.