[jbenedictocenteno]

Description of Change

Three changes to an install that has to give up installed apps to make room.

• The file is read through first (Refs #103). An install from a file overwrote what was installed before the file was known to be whole: a cut file cost the app it displaced. When the plan gives something up, AO_AppMgr now reads the file once before anything else, with the new kdrv_image_check: the header chain against the file's length and the SHA-256 the image carries. A file that does not hold together ends the install with nothing given up. A URL, a terminal install and a .kfw container are not covered, which is why the issue stays open.
• A victim's copy is written under a temporary name (Closes #104). The copy went to /sdcard/<app>.bin in place, so a reset or a pulled card left a cut image under the app's name. It is written as <app>.bin.tmp and put on its name by one new AO_Storage request, STORAGE_PAIR_REPLACE, which moves what is there aside, puts the copy on the name and puts the original back if a step fails. The name never holds a cut file.
• The CRC of each victim is taken in pieces (Closes #118). It was taken in one step, about 70 ms per MB with every Active Object below held back. The keep round takes it 512 KB a step, the app an install replaces included, and keeps the values in PSRAM. AO_AppMgr's own static shrinks to 2008 bytes.

Test Scenarios

• tools/host_tests.sh: 5531 cases across 8 suites, all passing. tools/check_layers.sh clean. tests/target in both variants, with check_ram.sh and check_starts.sh.
• A kodeOS build on this branch: size, RAM budget, layer rules, the MISRA gate (nothing past the baseline) and the tool tests.
• On a DVT board with a card that takes writes on one line only:
  • a file cut inside its first segment is refused at its header; one cut later, whose install would evict, is refused by the read-through in 0.2 s with the apps and the card as they were;
  • a whole file reads through (0.85 s for 3.1 MB) and installs;
  • a copy onto a name that is taken, onto a free name, and with a .bak already there: the whole copy ends on the name, nothing is left over, and the copy installs afterwards;
  • a reset in the middle of a copy leaves the file that was there whole;
  • a reset early in a write that evicted two apps: the one the write reached is reported gone, the other is kept, its CRC matching at start-up; a reset late in a write reports every app it reached;
  • an app updated over itself with no room for both: its CRC is taken in pieces (0.31 s for 3 MB) and the install completes.
• Not covered: a reset in the middle of a copy leaves <app>.bin.tmp behind until that app is copied again; nothing sweeps it yet.

Related links

Closes #104
Closes #118
Refs #103