deps, build: the pins catch up, and the loader is built here now

Fifty-two libavr commits and twenty-seven of pureboot behind, which is far
enough that "it still builds" is not the interesting part. It builds, both
modes, byte-identical across them, five checks green - and the image is
**byte-for-byte the 8004 B the board is running**, so the catch-up costs this
deployment nothing and a redeploy was ruled out by comparison rather than
skipped by assumption.

The loader is the gap that mattered. pureboot rode as a submodule for its
geometry alone, so the commit that pinned this firmware did not build the one
image this board cannot be recovered without - the same hole tempmon had.
`pureboot_add_loader(pureboot)` closes it on nothing but pureboot's own
defaults for the chip, and the 386 B it produces is byte-for-byte what the
board's slot reads back.

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

CMakeLists.txt

@@ -37,5 +37,15 @@ add_custom_command(TARGET fantemp POST_BUILD
                    COMMAND ${CMAKE_OBJCOPY} -O ihex -R .eeprom
                            $<TARGET_FILE:fantemp> $<TARGET_FILE_DIR:fantemp>/fantemp.hex)
 
+# The board's loader, built here rather than named from memory: consuming
+# pureboot for its geometry alone left the one image this deployment cannot be
+# recovered without outside the repository that pins it. Every parameter is
+# pureboot's own default for this chip - USART0 at 115200 on the 16 MHz crystal
+# `src/board.hpp` declares - and that is measured rather than assumed, the
+# image being byte-for-byte the 386 B the board's slot reads back. It goes on
+# over the wire (`--update-loader`), which is why there is no flash target
+# beside it: no programmer has ever been in this board's path.
+pureboot_add_loader(pureboot)
+
 enable_testing()
 add_subdirectory(test)